SAP authorizations function via the assignment of roles, which in turn contain authorizations. Now, SAP knows quite different role types. We explain which SAP roles exist and how you can use them.
Imagine you have to set up the FI authorizations in a company with 200 branches. For data protection reasons, it must be ensured that the employees can only see and edit the postings of their own branch. In addition, employees should have access to reports, and here, too, everyone should only see the key figures that belong to their area. In addition, it should be ensured that employees with the same task profile also have the same rights.
You can map all these requirements using individual single roles. However, you then spend weeks on the implementation and end up with a huge role landscape that no one can keep track of. But if you work with different role types, the chaos is kept within limits:
Single roles
Single and composite roles are the basis of the SAP role landscape. Single roles are the smallest unit. They contain authorizations and can be assigned directly to users. In this way, you can theoretically build a separate set of authorizations for each employee, in which you build a separate single role for each. This gives you maximum control and avoids unintentional over-authorization – as long as everyone only gets a single single role and you have an overview of the permissions it contains.
And that’s where the problem often lies in practice: As a rule, an employee has several single roles. Since SAP reads out authorizations additively, employees can be over-authorized without you noticing.
Imagine that you only assign read rights for an authorization object in a single role, but in another role you assign editing rights to the object. Now you assign both roles to a user (by mistake, because there is a time lag). The user can then automatically edit the object, because the more far-reaching authorization from role 2 overrides the restriction from role 1.
Composite roles
You combine several single roles in composite roles. Composite roles themselves do not contain any permissions, they are only the cover for the single roles. However, the user is not assigned an infinite number of single roles directly, but only a manageable number of composite roles.
For example, you could create a composite role for all FI employees in the tax department. This contains all necessary single roles. However, the users are assigned the composite role directly. The system recognizes the contained single role and assigns it to the user indirectly.
Composite roles – just like single roles – are created individually in each system and each client. They do not work across clients.
The great advantage of composite roles is that they make your role landscape much clearer. And providing new employees with the appropriate authorizations is also faster if you only have to assign the respective composite roles.
However, composite roles can be problematic if you need to change or add authorizations frequently. In this case, you need to analyze whether the new authorization affects the old ones. This happens at the single role level. If you then adjust a single role, you must also check in which composite roles it is installed and whether there are any conflicts. This means that you may have to do a lot of work when you make changes.
Business roles
At first glance, business roles look like composite roles: They comprise a whole set of authorizations, for example, they collect all necessary authorizations for a workstation. For example, the tax employees in our example only need the business role “Tax Administrator”. To ensure this, however, business roles can contain not only SAP single roles, but also all other (non-system) applications that the user needs.
Important: Business roles can only be assigned via IAM solutions (such as SAP IDM, SAP GRC or corresponding external tools). Unlike composite roles, business roles can be created across systems and clients. This means that when a new employee joins the company, he or she orders the appropriate business roles via the IAM application and is authorized via it on all systems and clients to which he or she must have access.
Good to know: Please do not confuse business roles with business partner roles. These, also called business partner roles, are not authorization roles. Rather, they are used to record and classify external partners in the system. For example, there may be business partner roles such as “principal”, “vendor”, or “landlord”. The role contains attributes that are recorded for each business partner and are relevant for the business relationship. However, you do not control any system authorizations through them.
Derived roles
Let’s assume you have built a single role with the authorizations to post cash receipts. All FI employees should have this authorization. However, the employees in the respective branches should only be allowed to post (and see) the documents that occur in your company area. You could now copy the single role for each branch and individually define, for example, the company code or the cost center (i.e. the relevant organizational level). In this case, however, you would have to edit each single role again for each future authorization adjustment.
Or you can use the finished single role as a master role and simply derive the roles for the individual branches.
Good to know: To create derivations, create the child role in PFCG (in our case, the role for a branch) and enter the name of the master role from which the menu and permissions are to be taken in the “Description” tab in the “Derive from role” field.
The great advantage of this is that future changes to the permissions only need to be made in the master role. All derived roles are automatically supplied with the changes as well.
In the individual child roles (i.e. the branch roles), you now only maintain the organizational levels to restrict access to the data.
Important: Always control the organizational levels via the corresponding button (PFCG -> Call role -> Authorizations tab -> Open in edit mode -> Organ levels button). You can also see the organizational levels as field values in authorization objects. But if you customize the Orgebenen in these authorization fields, they will be overwritten every time the master role is changed and the changes are applied to the child roles. Only if you customize the Orgebenen over the appropriate button, this expression remains, even if the authorizations are changed.
Important: You may not change the menu in derived roles. Menu adjustments are always made in the respective master role.
Value roles
Value roles appear at first glance like derived roles, but the difference is in the details. Value roles are also used to restrict access to data. However, they are used when this restriction is to be controlled by individual authorization objects instead of organizational levels.
For example, you might want to separate your branches by funds center instead of company code or cost center. You can now make the funds center authorization field an organizational level. However, this is not straightforward. Alternatively, you build a master role again, but coin out authorizations AND organizational levels. In the authorization object that controls the authorization check for the funds center, however, you enter only a dummy value in the corresponding field. You then stamp the correct value for the funds center of the respective branch in the respective value role, which does not contain any other authorizations.
Example: The object F_FICA_FSG gets the value in the master role in the field FM_AUTHGRC. The value role for the respective branch then only contains this object, which, however, contains the authorization group in the FM_AUTHGRC field that includes all funds centers for this branch.
Menu roles
You can also distinguish roles into menu roles and functional roles. In this case, there is a role that contains the authorizations in the correct specifications. However, the user menu is maintained in a separate, so-called menu role.
In this case the authorized transaction codes can be summarized in the menu role. Important: With this procedure the default values for the transaction codes must be deactivated, because otherwise the respective authorization objects are also drawn into the role. These are to be pronounced however in the functional role.
Menu roles are also used in the BW environment. Then, instead of the transaction codes, the respective reports are maintained in the menu to which the user should have access.
Important: A menu role can never be assigned alone. In order for the user to be able to access data, he always needs a supplementary functional role.
Front-end and back-end roles
With the introduction of FIORI, two new role types were added to SAP: frontend and backend roles. Whereby the strict separation softens when you run FIORI in an embedded scenario. This means that frontend and backend are combined in one system for you.
However, if you work with two separate systems, the role distinction is also important for you. Basically, the frontend role controls the start permissions for the OData services and the FIORI launchpad and contains the catalogs with the FIORI tiles as well as the groups. So the frontend role is responsible for what the user sees when they open their launchpad. Data access, however, is controlled via the backend role and therein via “normal” permission objects.
Portal roles
Portal roles are special roles that you only need if you connect a NetWeaver portal (JAVA) to your ABAP system. In these roles you collect, for example, permissions for iViews or folder accesses. They define – similar to the frontend role in FIORI environments – what the user sees when he opens the portal.
To do this, you create a portal role in the PFCG that contains the URL to the relevant landing page in the portal in the menu. You then need to create a system connection between the portal and the respective backend system before uploading the portal role from the PFCG to the portal. This is done via Content Administration in the portal.
Note: If you are using the Web Dispatcher, additional steps may be required!
Afterwards, users can do their work through the portal using data from the backend without jumping to the backend.
UME roles
UME roles are also roles that you need only in JAVA environments, i.e. in the portal. In contrast to the portal role, however, you collect permissions in them. On the one hand actions can be authorized. Roughly speaking, actions control which WebDynpro applications the user can use in the portal. At the same time, UME roles can also contain Java security roles (J2EE roles).
UME roles are created and managed via Identity Management on the AS Java.
J2EE Roles
We mention this role type only for the sake of completeness. As an authorizer, you usually have little to do with the administration of these Java security roles. However, since they can be part of the UME roles, you should be familiar with them.
Security roles allow the developer to restrict access to certain web resources such as URL or EJB methods (Java server components).
One thought on “Role types in SAP systems”