Exercitation ullamco laboris nis aliquip sed conseqrure dolorn repreh deris ptate velit ecepteur duis.
Close
The SAP authorisation concept
AuthorisationsA deep dive into SAP authorisations for the non-technical reader
In this blog, we aim to introduce readers to the technical world of SAP authorisations. This blog is intended for business stakeholders who are involved in the management of access in SAP. These include people who are involved in requesting or approving new SAP access, signing off SAP access reviews, or anyone whose responsibility intersects with access management in SAP.
There is often a confusion about who should be responsible for access management in SAP. Ultimately, it is the responsibility of the business part of an organisation, as SAP is implemented to help with the running of the business. IT should follow directions from the business.
This can be difficult to manage. IT may not have the understanding to grasp business access requirements, while business does not have the SAP technical knowledge to know what it takes to implement these access requirements in the system.
This blog post aims to alleviate a small part of this problem. It will dive into how authorisation is structured in SAP, particularly in the backend of ECC and S/4HANA.
Furthermore, this blog post is best explored after reading our blog post on the basics of SAP access, which gives a high-level overview of how a user can perform a task* in SAP. Additionally, if you would like to know more about roles in SAP, please refer to our blog post here.
*Note: When we talk about tasks, we are referring to all activities you can do in SAP, including business transactions (e.g., posting journals and creating sales orders), display activities (e.g., viewing HR records), IT maintenance tasks, etc.
How do we assign the right authorisation to users?
Each SAP user has a user master record created in SAP. Each user master record has a unique user-ID and password. Each user’s SAP access is tied to their user-ID.
A set of authorisation object field values is required to perform a task. These authorisation object field values cannot be directly assigned to the user-ID. Instead, a role is required to act as a ‘container’ for these authorisation objects. The collection of authorisation objects (along with their defined authorisation field values), contained in a role, is one-to-one generated into a profile. Via assignment of the role (with its associated profile) to a user-ID, the user-ID will be authorised for all authorisation object values inside the role.
Either single roles or composite roles can be directly assigned to a user-ID. A single role is one which directly contains authorisation objects (as shown in the above diagram). A composite role, on the other hand, is made up of other single or composite roles.
As mentioned before, it is not possible to directly assign authorisation objects to a user-ID. It is, however, possible to assign a profile directly to a user master record. This is not the standard SAP way of working anymore and is not recommended. A user compare programme (typically run nightly) will remove any profiles* directly assigned to user-IDs.
*Note: This applies only to profiles generated from roles.
SAP uses a mechanism called the Profile Generator (t-code PFCG) to create and maintain roles, and generate profiles from roles. PFCG carries automatic functionality to help ensure that all the relevant authorisation objects are contained within a role. This reduces the risk of the role having incomplete authorisation for the transaction that it intends to facilitate.
In practice, this is what happens when a role is built using PFCG:
- A role is created or already exists. If the role is new, the role name and description are defined before the role is saved.
- A transaction code is added into the new or existing role.
- In the background, PFCG checks an SAP table to identify the authorisation object field values associated with this transaction code.
- The identified authorisation objects and their fields are added to the role, partly with a defaulted value and partly left open. The administrator can then add more values to the relevant authorisation field(s).
- The profile is generated and becomes available for assignment to user master records. A role is only complete once the profile has been generated. This is why the role-building functionality is called the Profile Generator.
SAP also comes with thousands of template roles (often referred to as SAP standard roles) out-of-the-box. The names of these roles are prefixed with SAP_. These roles do not contain specific business requirements and only provide starting point from which other roles can be built.
To utilise an SAP standard role:
- Create a copy of this role in PFCG, giving it a name which meets the role-naming conventions of the organisation. Often this would begin with a Z_ or Y_, to indicate the customisation of a standard role. No role should be named SAP_: This prefix should be reserved for out-of-the-box predefined roles from SAP. This is important for administrative and organisation purposes.
- Define all relevant authorisation field values to meet business requirements.
- Generate a profile for the role.
SAP standard roles themselves should not be changed or assigned to a user. When a system upgrade or a new release takes place, all standard roles might get overwritten.
Diving into authorisation objects
The use of authorisation objects allows access to be managed to the level of granularity required by the organisation. Each transaction code has multiple authorisation objects associated with it; however, not all authorisation objects are included in the authority check.
As an example: These are the authorisation objects which are checked for t-code ME21N.
What are the functions of these different authorisation objects?
- S_TCODE gives the user access to execute the specified t-code: In this case, it allows the user to key in the t-code and arrive at the screen in which details of the PO can be entered.
- The remaining authorisation objects are those which provide typical additional restrictions for the task. These authorisation objects reflect the way SAP works. For example:
o In SAP, the organisation unit purchasing organisation represents a legal entity on behalf of whom all purchasing transactions are conducted. Only purchasing organisations are able to negotiate pricing, issue request for quotations (RFQs) and make purchases. All purchase orders have to be accounted to one purchasing organisation.
o Each purchase is made for a specific plant. When the goods arrived, they are delivered to this plant. Hence only those users with access to purchase for the plant can raise POs for it.
Standard SAP suggests the authorisation objects that are to be checked for each t-code. The figure below shows the standard configuration of authority check for t-code ME21N. The boxed area shows that the four authorisation objects which are checked for this t-code (image taken from t-code SU24).
It is possible to change the configuration of authority check using t-code SU24. If, for example, you do not use the organisation unit purchasing group, you can remove it from being checked when t-code ME21N is executed. The column Proposal in the figure above will say ‘No’ instead of ‘Yes’ as a result. However, this would usually require further ABAP coding to be done, which could open up the risk of insufficient authority check.
Additionally, this would also impact the role-building process. For example, if the column Proposal is changed from ‘Yes’ to ‘No’ for authorisation object M_BEST_EKG, this object will no longer be proposed when a role is built for t-code ME21N in PFCG.
Authorisation object field values
Each authorisation object is further associated with one or more authorisation field(s), which again determine a more granular level of access. For example, let’s explore this authorisation object and its field values:
(Click image to enlarge)
The authorisation field Activity (with technical name ACTVT) is one that you may have seen before. As the name suggests, this field determines what kind of activity the user is allowed to perform. Activity values are fixed and not configurable, and only certain values are associated with each t-code. Here are examples of some common activities:
- 01 = Create
- 02 = Change
- 03 = Display
- 05 = Lock
- 06 = Delete
- 16 = Execute
- 43 = Release
The authorisation field Purchasing organisation (with the technical name EKORG) determines the purchasing organisation(s) that the user is allowed access to. As part of the initial SAP implementation, purchasing organisations are defined and configured for the SAP system under IMG Customizing.
Together, the above authorisation field values for object M_BEST_EKO give the user access to create or change only, for purchasing organisation 3200 only.
Let’s take a look at an example below. These are the authorisation objects assigned to role PO_CLERK_0003. Each authorisation object is made up of one or more authorisation object fields, and each field has a defined value. This value provides a specific authorisation.
(Click image to enlarge)
Each authorisation object gives access to a different part of the access. For example: The values under the authorisation object M_BEST_BSA allows access to create or change (ACTVT = 01 or 02) purchasing documents with all types (BSART = *).
Let’s say this role is assigned to Adam and he needs to raise two POs (see the table below). By comparing the fields of the POs and the authorisations assigned to Adam, we can determine whether he has the appropriate authorisations to create these POs.
(Click image to enlarge)
We can see that Adam has all the required authorisation field values for Purchase Order 1; therefore he will be able to raise (create) this PO.
On the other hand, Adam does not have the authorisation to create a PO in purchasing group 005; therefore, SAP will give him an error message when he attempts to create Purchase Order 2. To resolve the problem, Adam can be granted the following additional authorisation:
The user buffer
In our blog on the basics of SAP access, we talk about how SAP checks whether user has appropriate authorisations to perform a task. Essentially:
- When the user starts a t-code, SAP checks whether the user has the authorisation object S_TCODE for this t-code. If so, the user is taken to the screen where the task is performed.
- Once on the screen, the user’s other authorisation objects determine whether or not they can complete the required details and save the entries/document.
How does SAP know what authorisations the user has? When the user logs into SAP, a user buffer is refreshed. This user buffer contains all the authorisations that the user has and can be viewed using t-code SU56.
For example, this is the user buffer for user MEHTAS. As you can see, all the authorisation objects, fields and values are contained within the buffer.
When the user starts a t-code, SAP checks against this buffer whether the user has the appropriate authorisations.
Why does SAP not go directly to the user authorisation tables? Authorisation tables are located in the SAP database, which is on a separate server from the SAP application itself. As user authorisations are constantly referred to when a user is logged in, it makes sense to allow this data to be easily accessible. The user buffer table is on the application server and built by fetching the user’s authorisation data from various tables on the database server at the beginning of the user’s SAP session.
When a user has the same authorisation objects from multiple roles, the user buffer will display the highest authorisation level of field combination, as shown by the three examples below.
(Click image to enlarge)
As we can see above, there is no excessive access given through the combination of these roles for object M_BEST_EKO. This is because the user buffer will read the ACTVT field separately for purchasing organisations 3000 and 7000.
Cross-pollination
As we have seen above, the user buffer captures the highest level of authorisation that a user has for each field combination of authorisation objects.
Consider the business scenario whereby a user has two roles:
- Role 1 to create transfer orders (document type UB) for purchasing organization 3000 and 7000, and
- Role 2 to create normal orders (document type NB) only for purchasing organization 3000
Therefore, these two roles have different values for authorisation objects M_BEST_EKO (purchasing organisation) and M_BEST_BSA (document type).
This is what the user buffer will see as part of the role combination:
(Click image to enlarge)
Or, as represented by the diagram below:
(Click image to enlarge)
For purchasing organisation 7000, the user is only supposed to have the authorisation to create/change/display for document type UB. However, through the cumulation of authorisations gained from Role 1 and Role 2, they now have the authorisation to not only display, but also create and change for document type NB in purchasing organisation 7000. This can lead to a breach in data confidentiality or, worse, human error or fraud.
This is sometimes referred to as cross-pollination. Cross-pollination is unintended and usually remains undetected unless discovered by accident. It can be picked up through an access risk assessment which specifically looks for segregation of duties (SoD) violations at user-level, but only if the related tasks are deemed critical enough to be in-scope of this assessment.
Possible solutions to avoid this unintended access are to:
- Change the business process so that the combined assignment of roles causing the cross-pollination can be prevented.
- Accept the access risk and define a mitigating control to detect and correct any use of unintended access.
- Build a customer enhancement to include an authority check on all relevant fields (in our example: activity, document type and purchasing organisation) which are combined in one authorisation objects.
- Assign one of the roles to a second user-ID for the same person.
Out of the above solutions, the second solution may be the most practical and cost-efficient for most organisations. The first and third solutions can be complicated and costly, while solution four can open up even more risks.
Closing note
We hope this blog post has helped you understand more about SAP authorisations and apply the knowledge as part of your work. If you would like to read more about roles, check out these blog posts on the principles of role building, the enabler role concept and step-by-step role-building in SAP.
Go to Newsletter edition 02 here.
