We saw that maintenance of roles is rather simple (How to find roles). Maintenance just consists of the CRUD (create, read, update & delete) operation on the role object. But what if a role is in use somewhere already? In this case obviously the referential integrity has to be maintained. Database people may be familiar with this requirement. But, can it be changed at all? Do we need to renew all approvals we received while assigning this role to an identity? Can it be done within the regular attestation?
Well some tough questions. Let's break the case down to the different occasions:
Well some tough questions. Let's break the case down to the different occasions:
Create:
To my understanding this case is well covered. Roles are an artifact of organizing the business. So it will be a business responsibility, which has to deal with its creation. Let's call this role the Business Architect.
In order to be able to use these roles for access management purposes they need to be underpinned by permissions to access systems. This can only be done in a joint effort with a technical role. Let's call it the System Architect.
In some environments - like the SAP universe - we often distinguish between Applications and System(line)s. So there might be even 2 technical roles: an Application Architect and a System Architect.
As all 3 types of architects are bound to a certain business domain as after all you cannot be a specialist for the whole world. So an overall coordinating Role Model Owner should be appointed to keep the role model clean and lean, comprehensible and free of uncontrolled redundancies.
In order to be able to use these roles for access management purposes they need to be underpinned by permissions to access systems. This can only be done in a joint effort with a technical role. Let's call it the System Architect.
In some environments - like the SAP universe - we often distinguish between Applications and System(line)s. So there might be even 2 technical roles: an Application Architect and a System Architect.
As all 3 types of architects are bound to a certain business domain as after all you cannot be a specialist for the whole world. So an overall coordinating Role Model Owner should be appointed to keep the role model clean and lean, comprehensible and free of uncontrolled redundancies.
Update:
 |
| roles are versioned |
Let's assume for this case that delete is just a special case of update. For purposes of backward traceability and reporting I anyway doubt, that we should delete IAM entities which we may be requested to report on later. But rather I think we should flag them as being out of use and keep them to be able to sum up all changes to an audit trail.
If a role for any reason is not yet in use you may pretty much follow the same procedure.
But if the role is or has been in use it simply cannot be changed anymore. Instead versioning comes into play. You may however create a new version of this role. The old version of this role will then be disabled for any further assignment. Only the new version can be assigned henceforth.
However in case the update is not just a convenience change, but there is an important reason for it; you may need a special process:
- Create a new role version,
- disable the old role version,
- send an application to all affected persons' superiors and
- let them confirm the withdrawal of the old role version and the assignment of the new role version.
- Of course you have to inform the affected individual as well.
Sometimes things are a bit more complicated in reality that they looked at first sight.
