Elements in SAP Authorization

As already discussed, roles play an important part in user authorization. In this post we will discuss about roles and other elements in SAP authorization such as profiles, authorization objects, authorization fields etc.

When a user is created, he needs some authorization to perform any activity in SAP. User is created via SU01 ”transaction code”. A transaction code can be understood as a command which when executed executes a program or report.

So when we want to create a user, we execute SU01 transaction code (also called tcode). After this tcode is executed, we get the necessary screen to create user (assuming that we have the other necessary authorizations to create user).

Roles are assigned to users in  ”Roles” tab in SU01. Roles are basically containers which contain tcodes, authorization objects etc. When roles are generated, we get profile which provides authorization. Tcode PFCG (Profile Generator) is used for creating and maintaining roles.

Some of the basic elements of SAP authorization are:

(1) Authorization object
(2) Authorization Class
(3) Authorization field
(4) Authorization
(5) Authorization Profile
(6) Role

• An Authorization Object is a collection of 1 to 10 authorization fields. All the authorization fields are checked simultaneously. This means that if an authorization object has two fields a1 and a2, then values in both fields will be checked simultaneously such that the two fields follow “AND” rule for that particular instance of the authorization object.

  An Authorization Class is a logical grouping of similar authorization objects (e.g. similar in the sense of functional module they support). It can be seen in PFCG how different authorization objects are logically grouped under different authorization classes like FI, HR etc. This we can also verify in tcode SU21 which is used for creating authorization objects. Custom authorization objects should always follow naming standard such that they begin with Y or Z. These authorization objects are logically grouped under authorization classes which are custom made and their names should also follow customer naming conventions.

• An Authorization Field can be defined as the smallest authorization unit against which a check is made. As already discussed earlier,  an authorization object can have 1 to 10 authorization fields and all the fields are checked simultaneously. An example of an authorization object is S_TCODE. It has only one field TCD. Another example is authorization object S_TABU_DIS which has two fields: ACTVT (which means Activity) and BRGRU(which means Authorization group-we will discuss this later). Object S_TABU_DIS is used for authorization related to Table maintenance and we just saw that it is a collection of two fields.

• An Authorization can be defined as an instance of an authorization object. An authorization object can have different set of field values in a given role. For example: for authorization object S_TABU_DIS (discussed earlier), the field values can be ACTVT:03 and BRGRU:SS. It means that for tables belonging to authorization group(BRGRU) SS, the activity is 03 (i.e. display). So the user gets access to display certain tables (belonging to authorization group SS).

Now suppose the user also needs access to change certain tables and suppose those tables belong to authorization group AA. Then the above combination of “Activity:03 and BRGRU:SS” will not work to give the change access to AA tables. We will need another combination i.e. “ACTVT:02 (02 means change) and BRGRU:AA” to fulfill our requirement.



Assuming both the authorizations (display access to SS and change access to AA auth group tables) need to be given via the same role, we will have to use two instances of authorization object S_TABU_DIS in the role with two different set of values-”ACTVT:03; BRGRU:SS” and “ACTVT:02;BRGRU:AA”. Both these instance provide different authorizations, hence we can say that “An authorization is an instance of an authorization object”.

 

The above screen shows an example of how authorizations are maintained in a test role. We see various color coded lines:

1. The orange line represents authorization class,e.g. Human Resources (HR) in the screen above.
2. The green line below that represents authorization object – P_TCODE as shown above.
3. The yellow line (ZTEST123__00) represents instance of an authorization object i.e. it represents an authorization.
4. The pale blue line (TCD) represents authorization field.

• An Authorization Profile can be defined as a collection of authorizations. An authorization profile is created/maintained when a role is generated.