Examples of Restricting Authorizations to Elements of the Solution in SolMan 7.2: Definition of an Authorization Group

You can restrict authorization roles by element or attribute types. You can define an authorization group, assign element or attribute types to it, and create authorizations for these authorization groups.

You can also restrict authorization roles to subtrees of a solution. You can define an authorization area, assign top level structure nodes to it, and create authorizations for these authorization areas. See blog Restricting Access to Subtrees of a Solution in SolMan 7.2: Definition of an Authorization Area for more details.

The concept of the Authorization Groups in Solution Documentation

In Solution Documentation, we use a concept to allow authorization checks on object or attribute type level without the need of listing hundreds of object or attribute types in a special authorization role. Authorization Groups are defined solution-dependent. They have a technical name that is checked in authorization object SM_SDOC in field SMUDAUTHGR.

The authorization object SM_SDOC is part of the authorizations roles SAP_SM_SL_*. Please copy the SAP delivered roles to a customer name space before adjusting any role. For this exercise I used the SAP_SM_SL_ADMIN role which I copied to ZESAP_SM_SL_ADMIN role:

The Default Authorization Group is always available. It contains all Solution Documentation object and attribute types that are not assigned to any named Authorization Group:

As soon as you assign an object or attribute type to a user-created authorization group (not DEFAULT), it is not assigned to the Default Authorization Group because an object or attribute type can only be assigned to one Authorization Group. This allows defining authorizations on ‘all other objects’ or on ‘all other attributes’ that you do not want to name explicitly. They are virtually assigned to DEFAULT.

You maintain Authorization Groups with View Cluster Maintenance (transaction SM34) for View Cluster SMUD_AUTHG.

Example 1 – Authorization Group for test case maintenance

For example, you want to create a role for users that are allowed to see all objects but only may maintain test cases. For that you need to create an Authorization Group for test cases. You maintain the authorizations so, that you give them Display Authorization for the Authorization Group ‘*’ and Maintenance Authorization for the Authorization Group Test Cases only.

Select the solution for which you want to create Authorization Groups:

And maintain the authorization group ID and Title:

Now, you can assign a group type or even an element type to this new group. In the example below, the authorization group Test_Case_Maint can be used to maintain test documents only:

The user is able to create test documents. Additionally the user needs the authorizations provided with the roles SAP_SM_KW_*.

Combination of authorization objects SM_SDOC and SM_SMDDOC

Authorization object SM_SDOC:

Authorization object SM_SMDDOC:

Such a definition of the authorization group will allow the user to create all documents including test documents:

If you want to allow the user to create only documents of a specific document type you need to define this in the authorization object SM_SMDDOC.

You can also define usage of the document types in “Document Type Administration” (other document types would need to be not allowed to use for test case documentation):

Define Authorization Group to work with specific solution elements in a specific subtree

Example 2.1

In this example, I want to define an authorization group to access the content in a specific folder in my solution (Folder: Modular Processes) and to be able to perform only specific actions.

For that you need to first define an Authorization Area and assign the relevant subtree structure of your solution to this authorization area. Please review the blog: Restricting Access to Subtrees of a Solution: Definition of an Authorization Area for more information.

In my examples I use the authorization area MOD_CREATE_SALES for maintenance of business processes belonging to Sales (the subtree elements):

Next, you can define what elements and what actions you want to be able do in the authorization area. For that you need to define the authorization group:

Run transaction SM34 for View Cluster SMUD_AUTHG. Select the solution for which you want to create Authorization Groups:

Define the authorization group (e.g. E_MOD_PROC – Authorization group for access to the Folder: Modular Processes):

Then, assign the element types you want to be able to create in the authorization area (Solution > Business Processes > Modular Processes > Sales) assigned to E_MOD_PROC group:

This specific assignment allows to create ONLY folders in this one path (with subtree elements) Solution > Business Processes > Modular Processes > Sales; and to display all other information in other folders for the specific branch/solution:

The authorization role ZESAP_SM_SL_ADMIN was modified as shown below:

Example 2.2

Adjusting the authorizations to create any element (generally available) in the group type PROCGRP, in the folder Solution > Business Processes > Modular Processes > Sales with subtree elements:

Adding the group type PROCGRP to the authorization group E_MOD_PROC allows for creation of objects in the process level, in this one path (with subtree elements) Solution > Business Processes > Modular Processes > Sales:

Please note: This allows you to create those elements: “Master Data”, “Organizational Unit” and “Process”. Theoretically, you could create the same elements in the subtree if the elements would exist in the subtree what is not the case.

Example 2.3

Adding another group type DOCUGRP to the authorization group E_MOD_PROC.

You want to allow the users to create documents for the specific tree elements. For that you need to add additional Group Type DOCUGRP to the Authorization Group E_MOD_PROC:

Please note that the user will also need to have the authorizations for documents provided with the authorization roles: SAP_SM_KW_*.

This allows to create documents in the process level, in this one path (with subtree elements) Solution > Business Processes > Modular Processes > Sales:

On the process level:

Including the levels below (e.g. process step) if the object usage is defined for the levels below in order to apply the authorization for:

In the above example, creation of documents is defined for a process and a process step AND allowed by the authorization concept.