When talking about child roles and parent roles and a role structure in the IDM MMC perhaps pictured upside down, it can be confusing sometimes, which roles to link, so that the right pattern of privilege inheritance will be implemented.
Consider briefly the following Role Model
Figure 1 : A three tier role model. Note that while today in most organisations privileges are directly assigned to users (like the two on the right), in future privileges should only be directly assigned to users in exceptional circumstances (example system accounts).
Roles and Privileges on SAP NetWaver IDM
The above Role model can perfectly well be implemented on SAP Netweaver IDM 7.2 There is no special provision for IT Roles. They are treated the same as Business roles. So if we require business roles three levels deep, then IT Roles will become the fourth level and child roles of the third level. In the diagram above in effect they move back up above the red line and become 'Roles Level n'. If the role model is very simple, all roles can be created in the MMC IDM Management Console. If the number is substantial, they should be created in the WEB Management Interface.
It is even perfectly possible to create special web based work flows with one or two step approval mechanisms to create new roles and link them into the existing role hierarchy. This way the role owner can be kept in the approval loop.
Figure2 : Two ways of showing the roles in the MMC IDM Console
Note: That the representation on the left is actually technically correct, with the parent role ‘Manager’ automatically inheriting the privileges of the child role ‘Employee’. In effect the parent role is linked to the child role by selecting the higher Manager role and right clicking ‘new’ and then ‘Link to role’ Employee. The leaf entries are the privileges. In the case of the Manager and the Approver they each have some direct privileges attached plus they inherit all the privileges from the child role employee.
Note: Before introducing the RBAC model, only the bottom level privileges will have been read into in the Identity store together with any time dependencies by a process called ‘initial load’. This means these dependencies no longer exist in the AS ABAP. Previous time-dependent assignments are lost in this step; therefore, you no longer have a history of such assignments. You also no longer see future assignments in the AS ABAP.
Note: Please be aware, that as we insert the role model between the users and their privileges, any directly assigned privileges will not disappear! If a user already has a privilege, or inherits it in another way, nothing will happen by inserting a role in between. What does happen is that IdM stores the fact that a privilege is accrued as a result of a direct assignment (Y/N) and it also stores an attribute Inherit_count n (i.e. from how many parents a privilege is inherited)
So while we won’t start with a clean plate when we implement provisioning, we may have to revisit this fact but in the near future, when we integrate GRC to be compliant!!!!! In other words we may have to delete all direct privilege assignments and re-provision via the role assignment process and then add again. This will of course involve a lot of processing and may cause temporary disruption to the user!
NOTE: Only when the last reason for having any role or privilege assignment is removed, the privilege itself will be de-provisioned on the target system.
