Role Engineering and Maintenance Process

Definition of application role is not an easy task. It often can’t be performed by one person only.

Application roles are created by engineers of the applications to which these roles are defining access. The Application engineer is the position that has the most knowledge about technical implementation of access to the application. Even though Application engineer has knowledge about the application, he may not have enough knowledge of identity management system. So this definition is often product of cooperation of Application engineer and IGA administrator.

To offload IGA administrators, IDM must support application engineers with good interface for role definition. As midpoint configuration may be very complex, the interface must abstract of midpoint terminology and structure and provide the application engineer structured data in a form that the skilled IT engineer is able to fill intuitively or after minimum of learning.

Definition of business role is easier, and therefore the business roles may be created and updated by business personnel.

The high level process for engineering of business roles is the same as for application roles. Main difference is the visual form of the role. Business role does not usually contain any technical configuration, just list of application roles together with business data.

At least at beginning the business roles definitions and configuration will be managed mostly by Role manager or IGA administrators based on his requests.

By their nature, application roles are defining access to applications. So, they require applications defined prior linking new role to them. Application objects may be imported automatically from application inventory, or created manually by application engineer.

Application object can collect business information about the application. Or it may be just link to application inventory.

To clearly understand the difference between application and application role. Application is an administrative object describing application as a business target that the access definition (the role) relates to. Only roles contain technical components that construct user entitlements and access to the application.

If no application definition exist in IDM, the Application engineer will create the Application and fill-in basic information. After the application is defined, Application engineer can start designing the application roles.

Lifecycle of the application is mostly independent of lifecycle of the roles. Application lifecycle may be read from application inventory, or defined manually by Application engineer (as described on the schema above). The Role engineering process does not define lifecycle of applications. But modification of the application lifecycle state may be driver for modification of the role.

The separation of the application from the process is due to the reduction of complexity and increase of the flexibility of the process. Lifecycle of applications is managed in organizations in other systems that IDM.

Schematic design of an application.

It is important to note that modification of some components of the role affects also all users the role is assigned to.

Role owners or IGA administrators may modify different components of roles. If just business details are updated (e.g. description, owner), then the update does not affect assignments of the role. But, if the provisioning definition of the application role or roles assigned in the business role are updated, then recomputation of actual role assignments is needed.

Such update and recompute of role assignments may generate a large number of operations. This is not big issue in case of automated provisioning. The IDM systems are designed to handle this. It just may take some time and resources.

But, in case of manual provisioning tasks, the update (e.g. update of 1 new manually provisioned application assigned to 100+ users) may generate large number of manual provisioning tasks. As people make errors and different people work differently, some provisioning issues in this case may (and will) happen. These issues must be handled by the IGA administrator.

Approval schema may vary in implementations based on business requirements and priorities. If the control over the process is priority, then Role owner should be included in every role modification. If the priority si speed and throughput, then the Role owner can be just notified about the updates.

There may be even different approval schemas defined for specific role modifications. E.g. adding application role into business role may require approval of both roles, but does not need approval of Role manager in some implementations.

Update of application role can affect more things - if technical details of provisioning are updated, the recomputing of users with the role assignment (direct or indirect) will be needed. The recomputing may become quite resource intensive operation when the role is assigned to larger amount of users.

Another kind of issues may appear in case when definitions of manual operations are modified. Not all updates are adequately described in working procedures of operation teams or even wasn’t anticipated in the design. Manual intervention and cooperation of Application engineer and IGA administrator may be needed in such cases.

Update of business role is probably the most common operation in the process.

Most often it is the addition or removal of an application role from the business role. As said above, specific workflow may be defined for this operation. Because 2 roles are affected - the business role being modified and also the application role that will be included into the business role. Owners of both roles should approve this operation.

Application updates affect the Role engineering process only if any modification of application roles are needed. Not modification of application objects.

Decommissioning of application roles means that the connection to the technical components of the access (groups, profiles) in the target systems is lost. Therefore, it may be necessary to delete also these objects after decommissioning the role.

Reorganization or end of business activity (e.g. project) may be one of the business drivers for decommissioning of business roles.

When all role assignments are removed, decommissioning of the business role is just administrative operation in IDM. No object outside IDM are deleted.

It is important to note, that even if decommissioning of business role may be technically easy and straightforward operation, it may be quite complex from business point of view. Some users may still need parts of the business role (will need to keep access to some applications) even after the role is removed. In this case, these application roles must be assigned to the users individually prior the business role decommissioning. The analysis of which components of the business role must be left assigned is a matter of IGA administrators and the Role manager.

When decommissioning an application, the IGA administrator must decommission all application roles. However, the decommissioning of application is only administrative operation in MP.

As said above, the separation of the application from the process is due to the reduction of complexity and increase of the flexibility of the process. Lifecycle of applications is managed in organizations in other systems that IDM. For this reason, it is appropriate to use decommissioning of application only as an initialization of the application roles decommissioning and remove the application object at the end.