Identity Governance and Administration (IGA) is the process of managing access to applications and
services for your users across the organization. Put simply, it is the process of ensuring that all users
have the right level of access in order to do their jobs, that nobody has any access that they do not
need, and of providing proof of this when required. You can read our previous blog [link] for a more
detailed explanation of IGA.
There are many IGA platforms on the market, but the terminology can be impenetrable if you are not
familiar with the technology. In this blog, we will describe the key features you can expect from an
IGA platform.
1)Identity Lifecycle Management
Identity Lifecycle Management is the process of determining exactly what level of access a user
should have at every stage of their relationship with the organization, and ensuring that this is always
kept up to date. Key events in the lifecycle are Joining (when the user first joins the organization),
Moving (when they move or change role) and Leaving (when the leave the organization) – this is
sometimes referred to as the ‘JML’ process. At each stage, the users access is likely to change, and
the IGA platform should calculate those changes in real time.
Typically JML events are synchronized from an ‘authoritative source’ – for employees this is usually
the HR system. Data in these systems is considered to be accurate, or ‘authoritative’, and therefore
drives the identity lifecycle.
2)Provisioning
Provisioning goes hand-in-glove with Identity Lifecycle Management, and automates the creation
and management of access across all applications in the organization. Typically, if the IGA system
determines that a user should be granted access to a particular application, the IGA system will
‘provision’ an account for the user in that application, ideally in real time. Provisioning means
creating an account for the user, so they can log into the application. It also means keeping that
account up to date – so for example if the users’ surname changes, we can ensure that the surname
is updated in the connected application as well. Finally, provisioning also includes de-provisioning –
this means that when access is no longer needed, the IGA system can automatically disable or delete
the account in real time.
3)Role Based Access Control
The IGA system should be built upon a flexible Role Based Access Control (RBAC) model. RBAC means
the mapping of access to organization roles – essentially it is a set of rules like ‘all users in Sales get
access to Salesforce’, which can be used to ensure that users always have the right level of access.
The RBAC model should be flexible enough to fit with the organizational hierarchy, but also rigid
enough to bring some order to management of access, and help you to avoid a ‘free for all’. Look out
for the ability to support ‘Birthright access’ (access which applies to all users, regardless of role) and
the ability to have multiple, overlapping role assignments. In the real world, organizational roles are
messy – your IGA platform should be able to cope with that.
4)Coarse and Fine Grained Access
Managing access is not just about whether a user can have access to a particular application – in
many cases we also need to control what the user can do in that application. In IGA terminology, we
need to be able to manage both ‘Coarse Grained’ access (which applications the user can access) and
‘Fine Grained’ access (what permissions the user has in those applications), with the ability to map
both types of access to the RBAC model. For example we may have a role of ‘Financial Controller’ –
at a Coarse Grained level it should give access to the Finance system; at a fine-grained level it should
allow access to the Accounts Payable feature in the Finance system.
5)Self-Service
Self-service features allow end users to help themselves when they run into access related problems,
and also provide a means to keep personal information about users up to date. Common access
problems include forgotten username or password, preventing users from logging into applications
they have access to, so the IGA system should provide tools for users to recover or reset their
credentials. Also, users may want to view their access and add or request access to additional
systems – so a facility to allow them, to do this without needing to raise a helpdesk ticket is essential.
Also, although some data we hold about users might be stored centrally, for example in the HR
system, there may be other data such as personal email address or phone numbers which we are
better off allowing the individual to manage; when these details change, the IGA platform should
provide self-service tools to allow users to update the information, which we can then synchronize
back to the applications which need it.
6)Access Requests
Access requests allow users to request additional access to applications, roles or entitlements on
demand, when they need it. Typically access request will be initiated through a user portal, and will
include approval workflows allowing the relevant application owner or manager to review and
approve the request before access is granted.
Access requests are an important feature as, if deployed properly, they can significantly speed up
deliver of the IGA platform. A common issue with IGA projects is an attempt to model every role
within the organization which can be extremely time-consuming. A self service approach to access
requests can alleviate this burden, as users can request access on demand as they need it, allowing
the organization to focus on automating the 20% of roles which cover 80% of scenarios.
7)Certification
Certification is a core capability in terms of ensuing that the organization is aligned with compliance
requirements. Certification is the ability to require managers and/or application owners to review all
access to a particular application on a regular basis, and to validate for each user whether or not they
still need their access. Typically, certification efforts are organized into ‘Campaigns’ focused on a
particular application or set of applications, which recur on a regular basis throughout the year – for
example every six months. Certification features will allow managers to review a list of users with
access to their application, to understand how they came to have their access, and to take action
where actions is no longer required. This could mean disabling the users account or removing a role,
or it could mean delegating or escalating the certification request to someone else in the
organization who may know better whether or not access should be maintained. Reports should be
available which can be provided to the audit team to support ongoing compliance and general good
corporate governance efforts.
8)Micro-certification
Micro-certification is similar to certification – but occurs on an individual, timed basis rather than as
part of a campaign. A common use for micro-certification is the ability to require a manager to
review a contractor’s access every thirty days and determine whether they still need their access.
This is particularly important for users like contractors where the identity lifecycle is not driven by an
authoritative source such as HR, and therefore there is no automatic notification of an end date
when the user leaves. Micro-certification provides a means to contain the risk with access being left
open for users that no longer have an association with the organization.
9)Delegated Administration
One of the core challenges with identity Governance and Administration is that much of the burden
for managing digital identities tends to fall on the central IT department. This is inefficient and also
often ineffective, as in many cases the IT department is not well placed to make access decisions –
usually, managers from across the organization know who in their department should have access to
what. This problem is exacerbated when we think about management of external identities – for
example those from partner organizations. Delegated administration is the ability to delegate aspects
of the identity governance administration system to individuals from across and outside of the
organization to manage identities locally, whilst ensuring that this is done in line with identity
governance and access policies set centrally. This has the effect of significantly reducing the burden
on the IT department but also of placing identity governance
In the next chapter, we will take a look at different types of identity lifecycle that are found in typical
organizations, and how these features work together to support them.
Comments
0 comments
Please sign in to leave a comment.