A CRM user needs both a business role and security role to function. The business role determines the the CRM functions which appear in the user’s UI. The security role contains the backend authorizations which are needed to execute the different CRMapplications that are exposed to the user through the business role.
Since, the security roles are meant to authorize the components of the business roles, the business roles must be completely defined before we can start work on creating the PFCG roles. Another pre-requisite is that SU24 entries are already maintained for the CRM applications (Please refer to the posts on SU22, SU24 and SU25 for a basic idea on check indicators and their maintenance). Unlike in ECC, the CRM applications are not transactions but BSP applications which in turn map to external services. Hence when looking up the SU24 entries for them we choose external service as shown in the screen below.
The actual check indicators for a CRM UI component is shown below in the detailed screenshot. SAP CRM comes with a new authorization object UIU_COMP. This authorization object is checked when a new CRM application/ web service is launched and corresponds to the S_TCODE object for transactions. The different fields of the object COMP_NAME, COMP_PLUG and COMP_WIN serve to identify a single CRM application service. In addition to the UIU_COMP object, other authorization objects will be checked depending on the application being secured.
Although, its technically possible to manually add individual services to the role menu and maintain the authorizations for the components in role maintenance, SAP has provided us with a tool to create a PFCG role once the Business Roles are completely defined. The tool is in the form of a program CRMD_UI_ROLE_PREPARE which can be launched through SE38 transaction. The selection screen for the report is shown below
During customization of Business Role we have seen that each business role is tied to a single security role. We can use either the business role or the security role to run the report. The report internally checks the definition of the business role to create a text file with the appropriate menu links for the security role. The text file is saved in the standard sap work directory on the presentation server (user’s PC). The report also generates the log file shown below.
To create the menu of the new security role, we just go into the menu tab of the role and import the text file which was just created bny the report. With the menu created, the authorizations can be maintained as in the case of any other security role.
The concept of parent and derived roles was introduced by SAP to simplify role administration tasks. Its specially helpful while mapping security for large enterprises spread across multiple geographies or divisions. A child role derived from a parent role will have all attributes (transactions/ authorization object values) same as it parent except the values of the Organizational Level fields (plant, company code, sales organization). Thus maintenance is simplified as only the org levels need be maintained at the derived role level. This also ensures that there is no opportunity to make mistakes during authorization maintenance for the multitude of derived roles and also reduces testing effort for roles.
Creating the parent role follows the same process as creating any other single role. In the example below we create a global role “Z_CREATE_SO_GLOBAL” which allows the creation of Sales Orders (transaction VA01) for all company code, sales orgs.
With the parent already defined we create a child role “Z_CREATE_SO_US” which allows SO creation for the US companies. We maintain the parent role name as shown below.
The menu for a derived role can not be individually maintained as all entries are inherited from the parent.
Now we maintain the org levels values relevant for the child role. In the example below, we have used a dummy value of @ but in a production system the correct value for org levels should be used. The other other need not be maintained at this stage. Now we save the authorization entry for the derived role.
To populate the rest of the authorization values for the child role, we go into the authorization maintenance screen for the parent and click the button “push from gl”. This option pushes the non org level values from the parent to the child role and generates the profiles for both.
The most critical success factor for a parent-derived role concept is how well, the different business processes mapped by SAP roles are mirrored across the different divisions in an enterprise. In other words, a parent-derived role concept will not be very beneficial in case an enterprise follows different business process in its different subsidiaries.
Till now, all our discussion on role administration has been concentrated on creation and maintenance of single roles. A single role as we have seen till now is a collection of tcodes and/or authorization objects. However in addition to these, SAP also allows to create composite roles which contain one or more single roles. In this post, we will discuss the tecnical and business reasons for working with composite roles.
During role creation, the PFCG initial screen allows us to choose whether we create a single or composite roles. Once created, there is no way to changing a single role to a composite or vice versa. In the screen below, we look at the role definition of the SAP_AUDITOR composite role provided by SAP to allow the use Audit Information System (AIS). You will notice that the individual tabs inside PFCG are different from those for a single role. for ex, we do not have the common transaction or authorization tabs. Instead we have the Roles tab and also a menu tab. The roles tab allows us to specify any number of single roles that constitute the composite role as well as the system for the roles. This is important in a SAP system with CUA installed as a composite role defined in the central CUA system can point to roles defined in the child systems.
Even though transactions can not be directly added to a composite role, a composite role can have its own menu structure. We display the same through the Auditor role provided by SAP
Depending on role design or user assignment strategies, composite roles can be used in a number of ways. Lets look at a few scenarios using composite roles.This is not an exhaustive list in any way but just meant to give an idea of the common uses for composites
Single roles are mapped to tasks performed by users . Since a typical user performs multiple tasks, the total access for a user is represented through a composite role which includes the individual task roles.
Access is divided into transaction role ( which contain transactions but no authorization object access ) and value/controller roles (authorization objects but no transactions). Complete access is represented through a composite role with the transaction and value roles.
The entire system landscape consists of a number of separate SAP systems (like ECC, BW, SRM, CRM etc.) and users are administered through a CUA connecting the individual systems. A user getting role A in ECC will need the corresponding role B in BW and role C in CRM. This can be achieved through a composite role created in the central system which links the individual roles in the different systems.