Like SAP HR, SAP CRM also supports organizational management. Org Management allows the assignment of Business Roles to OM objects (like positions, org units, etc). The transaction to maintain OM structure in CRM is PPOMA_CRM. PPOMA_CRM allows us to search for particular OM objects and create new ones. The below screen shows a typical org hierarchy.
As you can see from the above, PPOMA_CRM is very similar to the ECC transaction PPOMA. Since we have already talked at length about Org Management in SAP HCM, I would not repeat the same here. Please feel free to have another look at the posts for Org Management under SAP HCM security.
For a user to work on CRM processes, the user needs to be assigned to a business partner. In the example above, we have the BP HR00160008 assigned to the Position 30002593.
SAP CRM allows role assignment in two basic ways, indirectly through Business Roles in PPOMA_CRM or directly through security roles assigned to user masters in SU01.
Indirecty role assignment is recommended by SAP as for large organisations with many CRM users and business roles it can lead to significant reduction in maintenance effort. For indirect maintenace, the Business Roles are maintained on a position for a user.
To maintain the business role for an OM object like a position, we select the position in PPOMA_CRM and the menu path goto>detail object>Enhanced Object Description which opens transaction PP01.
From the initial PP01 screen, we can maintain the appropriate value for Business Role for the chosen position.
With the position linked to a user and a business role assigned to the position we are now in a position to assign a security role to the user. While its also possible to directly assign a security role to the user at this stage, SAP provides the report CRMD_UI_ROLE_ASSIGN to make our job easier.
The report can be run for both users or user groups. It basically looks up positions linked to the respective users, checks the business roles assigned to these positions and finally assigns the security roles corresponsing to them to the user masters. The report log after role assignment is shown below
It is also possible to directly assign a security role to a user rather than go through these intermediate steps outlines above. To make this work, in addition to the security role the user parameter CRM_UI_PROFILE needs to be maintained with the correct business role as part of the user master. This removes the need of maintaining the Business Role on the position. However, since all CRM users need to be part of OM structure, it makes sense to use the indirect assignement rather than the direct one.
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 idea for this post was suggested to me by one of the visitors of this blog, who had put in a comment around the use of value roles in security design. I though that the question was general enough to merit its own post instead of a reply to the comment. Let me first begin with a confession, though I have worked in a few set ups using this concept, I have never understood their effectiveness in security design. For me, value role create more problems than they solve. I agree that my views are colored by the projects that I have worked on and elsewhere, their use might make a whole lot of design sense. If any of the visitors have any experience in innovative use of value roles which really simplified security design, please feel free to comment. A healthy discussion on the subject will help everyone of the readers including myself!
The transaction and value/controller role concept revolves around creation of separate roles for transactions ( with S_TCODE) and authorization objects with org level values. The latter are the value roles as the individual values for the org levels are maintained therein. Elsewhere they are also known as controller roles or enablers, as they control the final access to a transaction.The transactional role in addition to S_TCODE also contain the authorization objects which do not have org level values. Since the value roles do not have transaction in their menu, the authorization objects are manually added to them. During assignment, both transaction and value roles need to be assigned to a user (sometimes via a composite role). There is no hard rule around the number of transaction or value roles. In a typical scenario, a transaction roles might be created to map the different jobs defined in the enterprise. A possible starting point of such a design will be provided by the user-transaction matrix. After the transaction roles are set up, a few broad value roles are created with authorization objects needed for a functional area (SD, MM, HR, FICO etc). The number of value roles generally will be much lesser than the number of transaction roles and will have all or most of the authorization objects belonging to the functional area. We can also have separate value roles for display and update and also different ones for the different ones for the various divisions in the enterprise.
I believe the initial logic behind adoption of the value/controller roles was reduction in maintenance effort. For example, instead of maintaining tcodes and authorization objects in all roles, we just add the tcodes to the single transaction role and the authorization objects to the value roles. In fact, since SU24 entries are not involved (authorization objects are manually added to the value roles), value roles will be only be need to be updated for a new authorization object (i.e. an object not used in the transactions being already used). Some people might also consider it to be a cleaner design, to keep the transactions and authorization objects separate.
After knowing the background of value roles, lets explore the problems created by their use. For me the biggest casualty of the value roles, is the loss of all information contained in the SU24 entry for the transaction as transactions and the objects needed for its execution are present in different roles. Without strong documentation practices, we can often end up with a situation where no one has any idea why a particular authorization object was added to a value role. A direct result of the above problem, is the fact that most value roles have more authorizations than are needed for execution of the transaction present with a user through a transaction role. A further problem arises because in many cases SAP allows us to jump to different transaction screens by following navigation options in the menu for a tcode i.e. moving from a display to the corresponding update transaction. Even though SAP would normally check for update activity in such a case, a S_TCODE check might not be enforced. Hence, user would get access to an update transaction through the value role even though transaction role only allows the display version. There might be many other such cases, where access present in the value roles might open up extra access with the tcodes present in the transaction roles. Finally the security testing effort is also increased a great deal as without the use of SU24 to guide us, the only way to determine the complete access needed for a tcode is run a trace for each new transaction and check each of the value roles to ensure that they contain required access.
I have already mentioned my skepticism for the value role concept for security design. In fact, I am even unwilling to accept the argument about less maintenance effort for value roles as the same can be realized with a parent-child role based design. However, there is overwhelming majority of security installations which continue to use value roles. If any senior security experts are currently reading this post, I would sincerely request their comments on the same as its extremely probable that I am missing something about the potential benefits for value roles.
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.
Though creating a report in SAP BW is typically much easier than creating one in ABAP, most reporting users are involved in actually running reports and interpreting the results rather than designing them. As a result the task of designing reports is often left to a select group of power users who are well versed in the knowledge of creating queries and formatting their outputs into suitable form for the use of other users. The output of one or more queries formatted in excel, which might include charts or higlight different data rows or columns, to facilitate their use for enterprise level reporting are called “workbooks”.
Once constructed, these workbooks, or even direct queries, need to be rolled out to the end users. Since the queries and workbooks are defined on InfoProviders, exploring the InfoProviders in BEX Analyzer would show all the reports defined on them. BW also provides a way of saving queries or workbooks into select folders by the power users as shown below.
Technically the folders are implemented as SAP roles without any authorization data. The folder roles are just placeholders to store queries/workbooks. Once the folder roles are assigned to the end users, they can just look into the folders roles assigned to them rather than having to search for the individual reports under the InfoProviders. This is beneficial as typically a InfoProvider will have a huge number of reports defined on them, many of which might not be applicable for all end users. Also, saving the important reports in roles saves the user from having to remember the InfoProvider on which a report is defined. In fact, we can take this scenario a step further by actually hiding the InfoProvider button from the open query/workbook dialog so that an end user can only access the reports which are specially designed for them. Hiding of the InfoProvider button is accomplished through the use of the S_RS_FOLD authorization object. Adding the object with a value of “X” to a user master ensures that the InfoProvider button is hidden from view in the open query dialog.
To save a query or workbook two authorization objects are needed to be present with the user – S_USER_AGR and S_USER_TCD. S_USER_AGR should have change access to the roles where the reports are going to be saved. S_USER_TCD needs the value RRMX.
Since the folder roles are modified by power users rather than the security administrators, a different transport strategy should be followed for them. In case, power users design reports directly in the productive environment, folder roles should only be transported to production once during the time of their creation. Any subsequent transport will wipe out all the new reports added to them. In the second case, a report is deigned in the development environment, tested and then moved to Production. In such a case, folder roles need to transported similar to any other authorization role.
“Organizational Levels” (Org Levels) as opposed to authorization fields is another of the core concepts that we come across while creating roles in PFCG. We can access the organizational level values defined for a role by clicking the “org level” button in the main toolbar within PFCG.
In the role below, we see Org Levels like Company Code, Purchasing Org, Purchasing Group, Sales Org, Division, Plant, etc.
In the expanded view of the authorization data in PFCG, the org levels defined earlier appear side-by-side with the authorization fields. In fact, all org levels are also authorization fields but not all auth fields are org levels. For example, the org level Plant appears as an authorization field in two objects, M_LFPL_ORG and M_MATE_WRK. On the other hand the field Activity is not an org level. Once we maintain a particular value for an org level in a role, all authorization objects using the same org level as a field will automatically take the same value. Its technically feasible to break an org level, so that for a particular object, its value is different from its defined org level value but this defeats a the purpose of defining something as an org level.
Another difference between org levels and normal auth fields come to light while deriving a role from another master role. A normal auth field will be inherited by the child role with the same value as maintained in the parent but an org level can be maintained in the individual child roles.
Organizational Levels in most cases are intrinsically linked to the enterprise structure of an organization and largely determined during the customizing steps for the SAP systems. The below screen-shot from the SPRO transaction shows the options for configuring different org levels like company code, controlling area, purchase org, sales org etc. So its not really the security administrator who defines the org levels. He can only use the existing org levels defined during functional configuration.
Its possible to change an authorization field to an org level for the purpose of security by executing the program PFCG_ORGFIELD_CREATE. However, since this program impacts all roles which contain the org field it should only be run after a thorough analysis of all impacted roles. Also certain auth fields like Activity can never be changed to an org level.
Access to SAP system are assigned to users through roles maintained in their user master. In this article, we explore how access to the SAP system is extended to users through roles. We also talk about the related concepts of authorization objects and authorizations.
The transaction to create/maintain roles is PFCG. Lets create a role in PFCG and try to understand the various options available to us therein. We name the new role “ZTEST_HR_ACCESS” and click the “Single Role” button. (Note that you can follow any naming convention for your roles as long as they do not begin with SAP or /).
Inside, PFCG, there are again a number of tabs which need to be filled with data as part of the role creation process. We start with maintaining role name and description. There is also the option of specifying a parent role as shown in the diagram below. A child role inherits all tcodes and authorizations from its parent except the organizational levels (we will discuss org levels in a later article). The Long text field might be used as an audit log to track the background behind creating the new role.
In the menu tab, we maintain the tcodes that the role will have access to. In addition to tcodes, we can also add reports, queries and URL. There are lots of options to build the menu of a role. You can copy from an existing area menu defined in SAP, copy from another role or import from a text file.
Once we have maintained the menu for the role, we go into the Authorization tab. We have an option of generating a profile name or following our own naming convention. I would suggest following a naming conventions of our own (even though I have used the generated profile name in the example) as the profile name can help in subsequent reporting on authorizations. We save the new profile and click either of the two highlighted buttons, Change Authorization Data & Expert mode for profile generation to get into authorization data maintenance.
The next screen is for maintenance of authorization data. The different color codes define distinct security specific objects/concepts. Lets discuss these below
Blue Line – Role – In our case its the new role which we have just created “ZTEST_HR_ACCESS”.
Pink Line – Authorization Class – These group Authorization Objects which protect similar application components.
Green Line – Authorization Object – Though called an object, an authorization object is more akin to an OOP class. Its a template or structure with a number of fields each of which needs to filled up with appropriate data to allow access.
Yellow Line -Authorization – This is an unique instance of an authorization object with values specified for its different fields. Carrying the OOP analogy forward, an authorization is actually similar to an object.
Off-white Line – Authorization Field – These are the unique fields within each authorization object. Different authorization objects will have different sets of authorization fields.
To understand how security works at the application level, we take the example of the S_TCODE object. To start a transaction, a user needs this authorization object in his user buffer with the the transaction maintained as a field value. In the example below, a user with the new role would be able to start transactions PA30, PA40 and SU53. However, starting a transaction is only the first level of check, any number of different authorization objects can be checked at each step of the transaction. These checks are for presence of individual authorizations in the user buffer.
During role maintenance, we maintain all the open field values (marked by yellow triangles) so all authorizations become green. Once finished we generate the role, by clicking the button with the a circle and red and white quadrants. This final step is the most important step in the entire process as this creates one or more authorization profiles for the role. It is actually the authorization profiles present the user buffer that give access to SAP applications. The role is just helps in easier maintenance of authorization profile. Even now, its technically feasible to directly modify authorization profiles but is strongly discouraged from SAP. Once generated, the role can be assigned through PFCG itself or through SU01.
In the next article, we discuss the link between transactions and authorization objects. This will in turn help us to understand how the authorization objects are pulled into the role during maintenance.
The introductory article gave a glimpse of one of the thousands of SAP applications delivered as part of a SAP standard package. This article follows on from there and starts our journey on SAP security. It tries to answer three basic questions: What is security? Why do we need security? and How does SAP implement security?
Q. What is Security?
A. Security in the context of IT denotes giving access to users to only those sytem resources which they require to perform their jobs. in SAP, these resources generally take the form of either business application or administation tools through transactions, screens, tables, programs, reports, web services, etc.
Q. Why do we need Security?
A. SAP being an ERP solutions comes loaded with a huge number of applications which can be configured to map the business processes of an organization like procurement, manufacturing, sales, financial accounting, controlling and human resource mangement. It is imperative that only actual employees/business partners get access to the SAP system (Authentication). Further, each user using the SAP system should only have access to the applications relevant to their jobs (Authorization). For example, we certainly do not want an employee working on the shop floor to get access to see and update the bank details for other employees, a job typically reserved for the HR department.
Q. How does SAP implement security?
Authentication is ensured by having an unique user-id and password for each user maintained as part of the user master record. Any user trying to access a SAP system should have a valid User Master Record. In addition to the user id and password, a user master record also lists the user’s name, email, telephone and the roles which allow access to different applications.
Auhtorizations are implement through roles (or the older term activity groups) and typically assigned to users through their user master record. Each role also has one or more corresponding authorization profiles with different authorizations. Its the authorization profiles which actually give access to users.