Authorization for Role Assignment

Question

Dear Experts,
I have a scenario whereby a user is able to assign a set of roles to end-users but should not be allowed to do so for himself. I could only think of assigning user groups to the person's authorization which restrict him to assign roles to end-users from specific user groups. However, this is not desirable in our scenario as this means we need to maintain user groups for the entire organization (which is a huge organization). I would like to enquire if anybody has implemented similar requirements via standard/alternative means. Any suggestion and advice is appreciated. Thanks.

Answer 1

Louis,
I think this is a standard security and authorizations question, and not really HR specific.  You are correct in that the standard way to achieve this is with user groups.  However, it doesn't have to be as onerous as you are thinking.  The usual way of achieving this, of having an authorizations administrator or user administrator who can manage standard end-users but not him- or herself is to assign just that user to a group, typically called SUPER, and not worry about assigning groups to all the other end-users (or at least, not for this purpose).  You might also put all other high-power basis users, like the system administrator and any other security administrators, into this SUPER group, since you don't want anyone other than the super-superuser to manage them.  Then, you assign the user administrator role the S_USER_GRP authorization with the usual activities for user group ranges 0-SUPEQ and SUPES-Z.  This allows the role to manage users in all user groups except SUPER.
I would also only allow this role to work with authorization profiles starting with the standard T, and role names in the pattern Z.  Then make sure that this role itself is not in the Z* customer namespace, but instead in the Y* customer namespace, and this way you prevent the user administrator from getting through a loophole and being able to create or modify non-SUPER users and simply assign them to the User Administrator role as a way of bypassing the above restriction.
You should also not allow the User Administrator role to directly modify roles or profiles, only to create users and assign them to existing roles in the Z namespace.
I trust that this helps.
--Matt