IGA Deployment Methodology

IGA deployment and implementation requires significant amount of communication and manual work. It will modify the daily life of organization and results will not come the next day. Such large task needs some good business reason to be performed. And there are at least two of them.

Business performance: Easier and faster provisioning of access. People in organizations often struggle to get access to an application. It can take even weeks in some applications which directly affects delivery of new projects and organization performance.

Good IGA implementation may decrease this lead time from weeks to hours or minutes.

Security & Compliance: Good control over user access. Having good control over user access is one of main goals in information security. And real organizations are quite away from achieving this goal. Security managers struggle to get user access under control and know who has access to what and why.

Furthermore, good technical description of application roles enables easy deprovisioning of user access. The word easy means that the unexpected errors caused by removal of entitlement can be minimized. When such errors are minimized, security managers have easier life pushing people to remove unnecessary access. Especially when people know that creating access is easy and fast.

IGA is handling users, applications and roles and their assignments. Managing everything is hard task.

In ideal world, IGA is responsible for definition and management of relations between users and applications - in the form of roles and their assignments. IGA should not be responsible for management of lifecycle of users and applications. The lifecycle of these objects should be managed by other systems and just be read to IGA. Users are typically managed in HR systems, applications in application inventory systems.

When building IGA solution, try to load the users and application definitions from resources outside midPoint. If this is not possible (we are not living in ideal world) you can use midPoint as interface for registration of users or applications. Whole sets, or just part of them. Try to keep responsibility for registration and lifecycle updates of users and applications to teams responsible for them.

Definition of IGA roles and their integration with applications is mostly done in midPoint. Responsibility for design of the roles should be on application owners/engineers, or owners of the business roles. IGA administrators should be operating in the area as technical support.

Definition of business roles should be performed by their owners or Role manager. Role manager is the position who should define and modify business structure of IGA objects - e.g. business roles organization, description, ownership…​

This methodology is built on the foundations brought in First steps. It assumes, that midPoint performs provisioning.

Prior deployment, the engineer should identify and describe the authoritative sources of each set of users and how these users will be loaded to IGA solution, set it up in the midPoint - so the basic technology is up and is able to provision data.

Engineer should have configured resources and sources of users. MidPoint can provision the users to resources. Applications and roles are missing - but this is the scope of Identity governance works.