In this two-part blog (see Part 1 here), we highlight how to improve the customer experience around SAP GRC using SAP Fiori. We also look at some of the benefits to consider when thinking about modernizing and maturing the processes and technology which support access governance of SAP applications.
Fiori catalog design and security considerations
The use of Fiori apps within the overall SAP environment brings up the below key topics around SAP security and user access to the Fiori Launchpad and relevant Fiori apps. In recent SAP security implementations, we have educated our clients about the relationship between Fiori catalogs, Fiori groups and business/composite roles; a relationship that defines and drives the role design and list of tabs the user sees.
The following are the three main design decisions to consider when implementing Fiori-based security (Note: These design principles apply to all SAP systems implementations that plan to leverage Fiori):
- Determine which Fiori apps users can view within the Launchpad. A complete list of Fiori applications to be implemented allows the security/GRC team to clearly define the approach for Fiori catalogs, groups, and roles. Fiori groups dictate the user experience and are primarily driven by the population of Fiori applications in scope.
- Determine which Fiori apps each user should be assigned. Access to Fiori applications is governed by Fiori catalogs. Fiori catalogs should be designed to follow the concept of “least privileged access” meaning users should only receive apps that are necessary for their job function.
- Define any functional or organizational restrictions that need to be applied to Fiori applications. Fiori catalogs are added to backend technical roles that dictate what functions are possible and what data is visible within a particular Fiori app. These technical roles are then typically combined into composite/business roles for ease of provisioning and define which activities the end user can perform within each app for a given job function.
Our key considerations when designing Fiori security include:
- Developing a security role design matrix prior to building and configuring Fiori. This matrix will help validate and test the Fiori app design.
- Defining the custom Fiori catalog and group design. The design should contain the Fiori app, custom Fiori catalog, custom Fiori group and composite/business role information.
- Establishing a draft of the custom Fiori catalog/ group ID within the Fiori design spreadsheet. Please note the Fiori group ID description will be shown within the Fiori launchpad (see the screenshot below).
- Creating a Fiori design document for system configuration and the security role build, to allow for a clean Fiori security build.
- According to the Fiori design document, configure the Fiori apps via the Fiori Design Studio.
- Once the apps are configured the security team can now build roles to ensure the appropriate catalogs are added according to the security role design and best practices.
- After role build, unit testing should be performed using the restricted security roles to ensure all Fiori apps are working appropriately and to capture any additional authorization/OData services required.
- Any modification to roles or the Fiori catalog after the completion of unit testing should be re-tested to ensure all apps are running without error and required restriction for the role is still valid.
Technical considerations
To enable the latest user interface elements within the GRC environment, there are several prerequisite components and configuration items to consider.
- UI components — SAP Fiori for SAP AC and SAP UI components are required to be installed. Refer to the SAP Access Control 12.0 Administrator Guide for the complete list of components required.
- Activate oData services — In addition to reviewing the technical UI components required, there are initial setup tasks to activate oData services for Fiori Launchpad which are required to be activated. These oData services can be found within the SAP Help Portal within the SAP Fiori Launchpad content.
- Plan time for security design – Consideration should also be given to the design of the Fiori Launchpad, specifically related to the tabs and groups of apps that the user will see. Fiori apps require authorization objects as well as oData services for users to obtain access to the apps, therefore, it’s important to build roles with this in mind and allocate time for testing and resolution of authorization-related errors.
Lessons learned
Through our recent upgrade and implementation experience, we have developed a few lessons learned to share regarding the GRC Fiori design.
New approval apps
The new Fiori approval apps enable approvers to approve requests via their mobile devices, greatly improving the access request provisioning process. This feature provides an improved approval process for access requests. Firefighter approvers can now approve through the Fiori app on a mobile device and provide approved access to Firefighter IDs quickly to allow teams to troubleshoot issues in the production environment with a reduced approval time.
UX team involvement
We have seen many clients choose not to dedicate specific teams to Fiori UI/UX, but instead assign this role to the security team. It really needs to be a dedicated effort separate from security that works closely with the security team. Fiori UI built by security will not be user-centric, and Fiori UI built without security involvement will not be compliant. It must be a partnership. SAP provides out-of-the-box Fiori apps which are customizable. Customization to Fiori apps requires technical support by the Fiori UX team. Many of our clients do not have an in-house Fiori UX team, so plan accordingly for custom app requirements to dedicate additional resources and budget.
Design maintenance and documentation
In a traditional security design methodology, the security administrator can extract the role to transaction code mapping directly from backend tables. In the new Fiori design methodology, there isn’t a table or reliable source available which provides the Fiori app to PFCG role mapping. Identifying which apps a role contains is challenging, especially if hundreds of Fiori apps are in scope. Therefore, it is crucial to update the design documentation effectively and this often relies on offline documentation rather than system-generated information. While this is a current pain point, SAP continues to improve and add functionality to support this area.
Conclusion
Modernizing SAP GRC and supporting processes requires focus on user experience and SAP GRC end-users shouldn’t be left behind. Consider using transformation initiatives or major upgrades as a catalyst for moving to updated interface technologies and deploying Fiori apps. Mobile access approvals can be a starting point for introducing Fiori into the organization. Plan and budget for security and Fiori UI resources to ensure successful adoption.
To learn more, contact us or visit Protiviti’s SAP consulting services.
