As an Identity Management / FIM Consultant, it can be difficult sometimes to explain to people what it is that I do for a living. I mean, I’ve explained it to my parents on numerous occasions and I wouldn’t hold it against them if they still said “computer stuff” when people asked. The reality is that Identity and Access Management can be a really difficult concept to explain – in fact, colleagues and I in the field have continually highlighted that the 30 second elevator pitch for our services had to include some form of relatable example in order to make sense:
“Imagine you’re a student at a University and have 10 different logins in 10 different systems…” or “You know how when you start a new job and you have to wait a week for your login to be ready?”
Wikipedia will give you a complicated explanation, but for me, Identity and Access Management, as its name suggests, really comes down to managing two things:
Identities: In any given organisation, a single identity might exist within multiple systems, and so should be managed in such a way that identity information is consistent across all systems, enforced by an authoritative system.
Access: A role that an identity holds within an authoritative source system will dictate the level of access that an identity has in other systems. This may include creation of the identity in systems that the identity is not already in, managing roles and entitlements within that system, or deletion of an identity from a system when a role expires.
How do I sum this up in one sentence? Well, I generally tell people that Identity Management is about designing systems that ensure users have a level of access to the systems of an organisation that is appropriate to their role within that organisation, and that they are the same user no matter what system they are in.
IM, IAM, AIM, IDAM, IdM – What’s the difference?
The short answer to this question is that there is no difference. Whether you are referring to Identity Management (IM or IdM), Identity and Access Management (IAM or IDAM), or Access and Identity Management (AIM), you’re really referring to the same thing. Colloquially, ‘Identity Management’ is a term that inherently includes Access Management. Usage of these terms will vary from organisation to organisation (and even within an organisation), but they all really mean the same thing.
What are some key benefits of Identity and Access Management?
There are several key benefits that most organisations realise by implementing an Identity and Access Management system:
- Streamlined user onboarding through automated provisioning
No more waiting for accounts to be created and access to be provisioned – as soon as a user’s details go into an authoritative system, their access is automatically provisioned.
- Streamlined user termination processing through automated deprovisioning
In any organisation, it is highly important to ensure that a user’s access to systems is properly restricted or removed at user termination. IAM can provide this by automatically revoking access once a role has terminated.
- Synchronised Identity information between systems
By synchronising data between connected systems, IAM allows for consistency of data and for data changes to be managed appropriately across all systems within an organisation.
- Self-service capabilities
Whether it’s updating personal data, resetting passwords or requesting/approving entitlements, an Identity Management solution reduces wait time and empowers end-users to resolve their own issues
- Reduced Support Costs and Higher productivity
With accounts and access being automatically managed, along with users now being able to self-service their own personal data, entitlement or password requests, significant cost savings can be had in decreasing operations and support overheads. Decreased wait times will also lead to greater productivity and user satisfaction within the organisation.
- Regulatory compliance
By automatically managing access and entitlements within a timely fashion, IAM allows organisations to more easily meet regulatory requirements related to system access.
What’s an Authoritative Source?
Within IAM, an authoritative source is a system which is the “source of truth” for a particular piece of identity information. It is used to ensure that the consistency and integrity of identity attributes are maintained across different systems, which in turn governs access for identities within those systems. For each attribute associated with an identity, there is generally a single system that is considered to be the authoritative source for that attribute.
When an authoritative system provides values for an attribute, this value is disseminated to all target, non-authoritative systems by the Identity Management process and similarly, when a value is changed within a target system for an attribute that it is not authoritative for, the Identity Management process changes it back to match the value originally contributed by the authoritative system.
The authoritative system can also change on a per attribute basis. In some organisations, there may be a single system system that is authoritative for all shared attributes across all systems. In others, there may be multiple source systems providing attributes for the target systems. And, of course, there are many scenarios where a system can be authoritative for some attributes and a target system for others. These scenarios are illustrated below:
Of course, while most identities will still have a single authoritative source that initiates and drives an identity’s life cycle, as in the left hand diagram, most real-world scenarios will still see other systems having authority on certain attributes, as in the right hand diagram. An example of the latter would be HR being authoritative on name and end date, the Phone system being authoritative for telephone details and the Directory being authoritative for username and e-mail. IAM will ensure that the correct values are synchronised between the different systems, based on which system is authoritative on which attribute.
What Different Types of Identities Exist?
Although computers, printers, security groups and other entities within your organisation could be classed as identities, when we refer to identities, we’re generally referring to users, and users can come in all different forms. If you’re a large company, the identities you need to manage may include full time employees as well as contractors. If you’re a university, you may have staff, students and visitors. A not-for-profit may have staff, contractors and volunteers. No matter what type of organisation you’re in, chances are you have a range of identity classes represented, with a set of rules governing the level of access that each of these identity classes have in each of your organisation’s systems.
You might also find that some users may hold several different roles within an organisation. For example, an identity within a school might go from being a student to an alumni, then a teacher, then a parent, with some of these roles being held at the same time, and it’s important that you give thought to how your Identity Management system manages an individual whose identity spans several classes within its identity life cycle. In a “pure” Identity Management system, a real-world entity would map to a single identity within your system, however in practice it is more often appropriate to keep them as separate identity classes.
Having deployed IAM solutions in many educational environments, I can say that there are very few organisations that are comfortable joining a student ID to a staff ID, even if they might be the same physical person (such as at a university, where a student works part-time in the library). The general rule in these environments tends to be, “when a student is a student, they have a student identity; when they’re acting as staff, they have a staff identity.”
Difference Between a Role and an Identity Class?
Some might disagree with me on this, but I tend to define identity classes and roles as two different things. My reasoning is that identities of the same class often follow the same identity life cycle and require the same basic provisioning and access requirements, while specific roles may be shared across all identity classes. Eg, a full time employee may enter through an HR system and have certain access rights, whereas a contractor may enter through a visitor registration mechanism, and have lesser rights across the organisation, whereas both a FTE and contractor might both belong to the “Directory Administrators” role.
What is Role Based Access Control (RBAC)?
Role Based Access Control (RBAC) is the provisioning of access to a system based on a role assigned to that identity. Sometimes, this role may be implicitly defined based on attributes assigned to that identity, such as department, title, etc. or they may be explicitly defined through a role management system.
Either way, an Identity Management solution spanning multiple systems allows for access within one system to be defined based on the roles provided within another system. Hence, user access may be automatically provisioned or revoked from a single authoritative source. This is particularly important in situations involving staff termination, where removing access to roles within the organisation is extremely time sensitive, and is also of great benefit in providing ongoing automated access control.
Anyway, hopefully that should provide a bit of insight into the what we really mean by Identity and Access Management. If you have any questions, feel free to post them below!