Understanding SAP S4 HANA security roles is foundational to project success. SAP security role & user assignment can be an overlooked aspect of the project. It becomes very clear further into testing with security roles how important accurate security roles and user assignment is. This post will be for the non SAP security consultants that need to understand how the security roles work at a high level. It will help users who don’t necessarily have enough security access to go to the security tcodes but still need to understand roles & users available for that role. Today we are going to look at the basics of how security works in SAP. These are the key concepts that we will be going over:
- SAP S4 HANA Security Roles Concept
- Composite Roles vs Single Roles SAP S4 Security
- SAP S4 HANA Security Role Authorization Objects & Tcodes
- SAP S4 HANA Security Roles Organizational Levels
- SAP S4 HANA Security Roles User Assignment
If you’re looking for a more in depth view of holistic SAP S4 Security check out the latest version of the S4 HANA security guide: https://help.sap.com/doc/d7c2c95f2ed2402c9efa2f58f7c233ec/2023/en-US/SEC_OP2023.pdf
SAP S4 HANA Security Roles Concept
If you have wondered how SAP S4 HANA security roles works then you need to understand the security role concept. Let’s start with the end in mind to understand this concept. As a user will have your own ID and password that can log in to SAP. This will be unique to you. However, typically none of the authorization from your user will be based on your user ID directly. With 100s or even 1000s of SAP users, it wouldn’t make sense to have to set up access at a specific user level. Instead the concept is that all users will fall under a group of similar users. This group of users is called a security role. All users will be assigned to at least one security role but can be assigned to multiple.
To understand this concept better, let’s to an oversimplified example of users assigned to a security role. Let’s imagine that there is a team of users in an accounts payable function of a company. Their job is to log invoices into the system, run payments & look at reports to make sure all of the vendors were paid. If you can see this team of users will all need similar access in the system.
Instead of setting up that same SAP S4 HANA access for each and every user, the approach is to create a security role for accounts payable. This role will have all the functions required and can be assigned to any user. Now, imagine there is an issue in security where a user can’t access a certain aspect of the system. If you had to set up the access for each individual, you’d have to fix the same issue multiple times. However, since you created a security role with multiple users assigned. You can simply adjust the role and all the users will have the security fix.
Let’s take a look at this concept visually:
Now that we have the most simple example understood, let’s jump to understanding the two different types of roles. Composite roles & single roles
Composite Roles vs Single Roles SAP Security
To further understand how security is managed, it’s important to understand the different categories of roles. There is a concept in SAP called a composite role & a single role. The key difference is that composite roles are groupings of single roles & don’t contain authorizations that can be adjusted. A composite role is simply a grouping of single roles to ease maintenance of user assignment. To understand composite roles, it is necessary to understand a few best practices around SAP security roles.
In SAP there are a number of standard roles that are created to do the different functions required. These standard roles are all single roles and contain authorizations. For example, you could have a materials management role. This role will have access to the material master data & will have the ability to be adjusted to restrict access to only certain types of materials. The standard approach is to copy the standard SAP security roles and then adjust the authorizations required based on business need.
The other key concept is that typically you should have single roles for displaying data & separate single roles for maintaining data. It is very common to have a large number of users that should have access to display data. Having a single role that is for display allows for you to group a lot of display roles together for users without the concern of giving them access to change transactions.
Lastly, super user type roles such as administrators are usually their own category of single roles as well. The idea is that single roles should be targeted to specific functions so that it is very clear the authorizations that they allow.
This granularity of single roles would then make it cumbersome to have to remember to assign a large list of roles for every job function. Going back to our accounts payable role example that actually would have been a composite role. The reason being there would be single roles in to broadly view finance data, perform accounts payable maintenance functions such as invoicing/payment & lastly ability to run reports. These would typically be stored in 3 different single roles. Here is where the use case of a composite role fits in. Creating a composite role which is just a grouping of single roles allows for you to have one accounts payable composite role to assign to users.
A composite role will inherit all the authorizations for all the single roles assigned. Now let’s go back to that accounts payable example and take a look at this visually:
Now that we understand how composite roles are a grouping of single roles without any underlying authorization let’s take a look at single roles. Let’s understand the underlying authorization concepts of single roles that feed into composite roles. Single roles use a concept called authorization objects in order to form the basis of security. Additionally, Single roles are where the authorized transaction codes are stored.
SAP S4 HANA Security Role Authorization Objects & Tcodes
Now that we have the background on security roles let’s move to security role authorization and Tcodes. If you want to understand what a Tcode is in SAP check out this blog:
https://techconsultinghub.com/2022/02/04/all-about-sap-tcodes/
If you want to know how to find Tcodes assigned to a SAP security role or how to determine authorizations for a security role you came to the right place. A single role has two key components we will focus on. You can access this information through the Tcode PGCG. However, that Tcode is often blocked unless you’re a security expert so we will talk through alternatives in another blog post.
- Menu – This is where all the different Tcodes and menu options are available
- Authorizations – This list shows the authorization objects that can be adjusted.
This means you use the menu to find which tcodes are listed for a role. You go to the authorizations section in order to determine which authorization objects and which activities for those authorization objects have been assigned. Below, I have indicated the location of the menu in the PFCG role, which stores transaction codes and menu paths.
The next location will be the authorizations for the role. Here you can see where you can store and adjust the different authorization objects for a role.
Now let’s dive a bit deeper into how authorization objects work in SAP. The concept is that for many key categories of data or transactions in the system you can segregate who has access.
Let’s give an example to make it more clear. Going back to the accounts payable department example. Let’s say you have two teams of people. One group in AP only manages the financials for vendors that are government/utilities related (non purchase order direct bill). Another group only manages financials for vendors that have purchase orders. In this case you could have them managing vendors by the two different types of vendors. In SAP terms that’s the account group. Each vendor would have a different account group and there is a related authorization object (F_LFA1_GRP) that allows you to restrict by account group. You are not able to restrict the system by every single field, only by which fields have a related authorization group. Let’s take a look at how these authorization objects look in SAP
Let’s break down how this works. Each authorization object has two key options
- Activity – Add/Create, Change, Display, Delete, Display Change Documents etc.
- List of values for the field relevant for the authorization object (For example Account Groups)
This way for every authorization object you have the option of whether you can create, change etc. and for which categories. Another example is sales orders types, you can have an authorization object for sales order types. Then you could have create/change access per sales order type.
SAP S4 HANA Security Roles Organizational Levels
In addition to using different authorization objects that restrict various fields, usually document types etc., you can also restrict organization levels. If you want to learn more about SAP organization levels concept check out this blog:
https://techconsultinghub.com/2022/02/18/sap-s4-hana-organization-structure-overview-for-mdm/
While you are in PFCG for the role you can select the organization levels and from there you can assign company codes, purchase organizations etc. This will restrict a user to only be allowed to transact for these organization levels. Let’s take a look in SAP:
Now you have all the basics of security roles, let’s move on to assigning a user to these roles.
SAP S4 HANA Security Roles User Assignment
The last step is to assign users to roles. As a note you can assign both single roles or composite roles to users depending on the overall security decisions. You perform it by going through PFCG Tcode and assigning users through the user tab. See the location in SAP below:
Now we have done all the steps to set up security roles and assign to users at a high level. As a recap here is the overall process visually
I hope this provided a great overview of SAP security for non security project functional consultants. To learn more about the tables and Tcodes, consider subscribing below, as I will cover that in the next part of this series.