Using SAP Screen Personas to hide unwanted Elements
SAP Screen Personas is the recommended tool to hide unwanted fields, tables, tabs, etc. This simplifies the transaction and avoids errors. In Screen Personas you create Flavors which are overlays to adjust the appearance and behavior of the original classic UI. SAP Screen Personas does not change the underlying behavior of the original transaction. So, from a security perspective, authorizations to limit data and activities within the UI should still be applied to all users of the classic UI, regardless of whether they are using the original UI or the UI with a SAP Screen Personas flavor overlay applied. The value of applying a SAP Screen Personas flavor is that it minimizes the opportunity to access unwanted data and features, while maximizing the task efficiency of the user.
Consider separating out roles that assign Search objects from roles that assign Apps
if you want to create Line of Business collections of business objects for search to be assigned across multiple roles. Search results will link to whichever related apps are logically assigned to the user. As a general guideline, you should consider including the search object permission if the user has any app/Ui that uses the same Semantic Object. For example, where users are assigned, app Manage Purchase Orders, they should also be able to use Search to find Purchase Orders.
Refine your data authorizations where needed
You will need to align with the business on data access requirements based on your Enterprise model – company codes, plants, purchasing org, sales org, etc. Information Classification/Handling – what is sensitive and must be restricted and Organizational Structure – centralized vs decentralized. Default data authorizations are related to the OData Service and are managed using transaction SU24N. You can see the defaults delivered by SAP in transactions SU22. You can use transaction SU25 to adopt these during your initial system install and on upgrade of your SAP S/4HANA release.
You need to include key user roles in your Security Design
Key users are authorized to configure, adapt, and extend apps on behalf of other users. They typically make these changes in your development environment – like any other configuration – and the changes are tested and transported. Key user roles should be a composite role that includes Key user capabilities to configure/adapt/extend your solution and Regular business user role they impact (so they can see the impact of their changes).
You need to include configuration roles in your Security Design
Whether or not you have designated key users, you will still need to assign SAP Fiori apps to configure extend and adapt your SAP S/4HANA solution for your functional teams and your administrators. For example, to add custom fields, to configure workflows, or to configure certain outputs, such as advanced compliance reports. Typically, you should copy these roles to the customer namespace and refine them as you do other business roles.
Adding launchpad content requires creation of custom technical catalogs
Technical catalogs are cross-client and hold the settings needed to launch the app or UI, and any parameter mappings used when the app/UI is launched. Technical catalogs provided a layer of reuse to better manage and minimize launchpad content maintenance, particularly where tiles and target mappings are reused in multiple business catalogs.
You need to understand the relationship between authorizations and launchpad layout
Launchpad layouts do NOT have any impact on the content available to a user via the launchpad. The only impact of layouts on the custom business role is the assignment of the space (top level of the layout) for that role to the role. Within your solution you can use the Overview of Roles, Spaces, and Pages transaction /UI2/RSP_LIST to get an Overview of the Spaces and Pages assigned to Roles, and the tiles/links within them.
Consider user provisioning goals in naming conventions
You will need to establish naming conventions for your business roles and business catalogs. Certain naming conventions impact. You will need naming conventions for Business Roles – technical ID, Business Catalogs – catalog ID and catalog name, as the name is visible to business users in the App Finder, Technical Catalogs – catalog ID and catalog name. as the name is visible to administrators maintaining launchpad content, Spaces – space ID and space name, as the name is visible to business users in their launchpad entry page. The space name does not need to be unique, Pages – page ID and page name, as the name is visible to business users in their launchpad entry page. The page name does not need to be unique. A similar pattern of pages across analogous roles is recommended, Custom apps – technical ID. You may also want to have your own equivalent of the SAP Fiori ID – forma g.F1511A, which provides an abbreviated id for uniquely identifying that is visible in the User Actions, Semantic Objects – However, as a rule avoid creating Semantic Objects and use the closest fit SAP delivered objects. There are more than 3K delivered objects.
SAP_ALL cannot be used to grant access to SAP Fiori
SAP_ALL should be avoided, even in Development. Even once apps and tiles are assigned, adding SAP_ALL is a risk for access to unauthorized data. This can even include access to some settings that are system wide.
Conclusion
Think of a security guard monitoring a building – they are monitoring the building to make sure all the access points are working properly and not blocked or congested, just as much as they are monitoring to make sure no-one is doing something illegal or dangerous. In SAP Fiori, your security team are there to make sure you have what you need to do your job, and they are also there to avoid you (or your company) getting into trouble accessing data or features you should not be using, such as personal data covered under GDPR.
Our experts provide personalized demos after understanding the business needs. Click here to talk to our experts.