As we know, the standard Personas administration transaction in version 1.0 and 2.0 doesn't provide a way to segregate duties. Access to it is an all or nothing affair: once a user can run the transaction, he/she is allowed to perform all included features. This may cause an issue at customers where there is a demand to separate certain admin function accesses from those that flavor developers would use, for instance.
In this post, I'll show a possible method to introduce control over the individual functions of the transaction. This is certainly only an example, one could go much more granular if desired, but that would require significantly more changes than the method described here. I was trying to keep the "code disturbance" to the minimum, but even then, I couldn't avoid a one-line core modification so if that's a no-go in some environments, then this will not help. But if this is acceptable, then the below method may be useful...
The theoretical use case is to have two distinct user types in the /PERSOS/ADMIN_UI transaction. One for a flavor developer who needs access to certain admin features when working on flavors and the other is a user administrator who only maintains Personas access: user roles and groups, and assignment of users to the groups.
The following are the necessary steps / components to achieve this:
Implementation of an ABAP implicit enhancement
This will insert our authorization check right before the selected administration function is processed. The location is at the beginning of method ON_HANDLE_NODE_DOUBLE_CLICK of class GCL_SCREEN_HANDLER in program /PERSOS/ADMIN_UI.
The enhancement code (for easier copy/paste):
ENHANCEMENT 1 Z_PERS_ADMIN_AUTH_CHECK. "active version
* Check if the user is authorized to perform the requested activity
AUTHORITY-CHECK OBJECT 'Z_PERS_ADA'
ID '/PERSOS/OB' FIELD sy-tcode
ID 'Z_PERS_ADF' FIELD node_key
ID 'ACTVT' FIELD '01'.
IF SY-SUBRC <> 0.
message i048 with 'You are not authorized to perform this function'.
clear node_key.
exit.
ENDIF.
ENDENHANCEMENT.
This will check whether the selected admin function is allowed for the user and issue a popup message if not, then exit from the method thus avoid executing the function. The functions are distinguished from each other based on the selected node key string the transaction is using. This will be later referenced in the custom authorization object we create.
Program modification:
Update Apr-01-2015: Due to improvements to the Administration transaction introduced by support package SP03 for ver. 2.0 (SP05 for ver. 1.0), the below described modifications are not necessary anymore. The Administration transaction doesn't start with the User Maintenance, instead the blank subscreen is the starting point, so this clears the potential hurdle implementing the enhancement.
Unfortunately this is required because the admin transaction is coded to start with the User Maintenance view, which immediately accesses a function we may want to restrict. Interestingly the standard code also contains a blank screen (9900) which would have been a more appropriate initial screen and which is not utilized at all, so it is unclear why the User Administration was selected as the default starting point. We could avoid the whole modification if the transaction started with a blank subscreen in the right pane, before a function is selected.
To prevent going straight into User Maintenance, at least a single line of code must be modified. The modification is in include /PERSOS/ADMIN_UI_O01, PBO module CREATE_OBJECTS. In the highlighted line, screen number 9040 must be replaced with 9900.
If we want to correct a “cosmetic” issue, we also have to make a modification in PBO module STATUS_9000 where the initial screen title is set. Otherwise we will get the ‘User Maintenance’ title with our blank screen. This will not cause a functional issue, but if we want to change it, this has to happen here:
Instead of TEXT-013, we’d need a different string, for instance ‘Personas administration’.
Authorization object:
This is the custom authorization object which is used by the enhancement and needs to be created.
The available activities are restricted to those that may make sense in our context, using the button “Permitted Activities”. In our scenario only ‘01’ is used, the rest are there as an example. Other activities than '01' would make sense if we wanted more detailed authorization control inside an individual admin function, but as mentioned, this would certainly require more code enhancements in the transaction and maybe even more core modifications.
Authorization field:
The above authorization object is defined with three authorization fields. For the transaction code, a standard Personas authorization field is used (/PERSOS/OB). Activity is also the standard field (ACTVT). For the administrative function control, a new one is created:
Data element:
Domain:
Single values correspond to the possible node selection strings in the Admin transaction:
The list of administrative functions in the above screen shots is not necessarily complete; additional ones may be added as new admin features are introduced. For the full action list, refer to the ON_HANDLE_NODE_DOUBLE_CLICK method of class GCL_SCREEN_HANDLER where all available functions are listed.
Example roles:
We need some new roles for duty separation of developer and user admin. Two roles will be created using transaction PFCG.
Developer:
Authorization data:
For developers, this will not allow user and group maintenance but everything else.
User & group administrator:
Authorization data:
This covers the remaining admin functions for someone who is managing Personas access (groups, users) but doesn’t do any flavor development.
Now all what remains is assign the new roles to the appropriate users and we have access control inside the admin transaction.
- SAP Managed Tags:
1 Comment
