A subsequent article will look at how we can represent the SAP access a user has in the Access Risk Controls for SAP module in IBM Security Identity Governance and Intelligence.

Understanding the Relationship Between SAP Users, Roles and Transactions

To understand why the opening question is wrong, we need to understand how SAP manages who has access to what. The following figure can be found in the SAP documentation and many articles on the web. It shows the relationships between user accounts (SAP Users), access groups (SAP Roles/Profiles) and permissions/resources (SAP Authorizations, Authorization objects, fields and values).

We can see that SAP Users are mapped to Roles and/or Profiles. These may be composite roles or single roles, or composite profiles or manual profiles. These Roles and Profiles (lets just call them Roles for simplicity) contain SAP Authorizations comprising Authorization Objects that may have up to ten Authorization Fields with values. An Authorization can be thought of as an access rule.

Where are the transactions? These are defined as Authorization Objects, normally as a transaction code or TCODE. A user is not mapped directly to a transaction (or any other Authorization Object) they are mapped to a Role this is in turn mapped to transactions and other authorization objects. Other authorization objects may be represented as data in a transaction, like a company code.

So, we should be able to unpack the Role <-> Authorization mapping to understand what transactions a user has, right? Technically yes, we could do that. The problem is that may give a view that doesn’t represent the correct access for the user.

Understanding SAP Authorizations

This is because of the Authorization Fields and Values that can be associated with an Authorization Object (like a transaction) represent a scoping of that access. SAP may be setup to allow users in a role to run a transaction but only against the objects relating to a specific company, or only in read-only mode.

For example, have a look at the authorizations defined for a role.

This role, T016-ROLE1FB02, is allowing members of that role to access three SAP transactions; FB01, FB02, and FB03. However the way the SAP authorization model works, there is scoping applied to the access to these transactions. The Activity (ACTVT), Controlling Area (KOKRS) and Valuation View (VALUTY) fields provide that scoping. For example, the activity values of 02 (Change) and 03 (Display) mean that these three transactions can be run in read and write mode.

This is a simple example; many customer SAP environments will have far more complex authorization definitions with many fields and values applied to transactions.

Another level of complexity is that transaction codes (and other values) can have wildcards, so a role may cover a set of transactions and that set may change over time as SAP changes (but not be visible as a static list of transactions on a role). I may define a role to cover transactions FB** and at the time the authorizations were defined, the list of transactions covered by FB** is know, but over time other FB transactions are added that may change what the role represents.

So, back to our question… can we show transactions that a user can access. Yes, we could, by unpacking the authorizations associated with a role to find the transaction codes for that role and the roles mapped to the user. Does this make sense? Only when a SAP deployment is so trivial that there is no further scoping of transaction access. For example if a role gave users access to a set of transactions but there was no further limitation to what a user could do with those transactions, then knowing the transactions for a user would make sense and give a complete picture of what the user can do in SAP.

But, if there is any scoping of access or objects in a transaction (or wildcarding of transactions), then saying John Smith can access FB01, FB02 and FB03 does not tell the complete story as he may not be able to make and changes to data in those transactions or may only be able it run the transactions for a very small part of his company. In this case, presenting a list of transactions for a user is dangerous as it gives an incomplete picture of what the user can do in SAP.

In the next part of this article, we will look at how we can truly represent what a user can do in SAP using the Access Risk Controls for SAP module in IBM Security Identity Governance and Intelligence.