Introducing Identity and Access Management (IDAM) to people who are not familiar with it often provokes questions around capability, terminology, benefits, scope and, ultimately, “why should I care”? Hopefully I can shed some light on the world of IDAM and why it is so important to running a government department.
What is Identity and Access Management?
Identity and Access Management (IDAM) is a key technology that enables an organisation to realise core business benefits, specifically with regards to cost savings, management control, operational efficiency, security, compliance and business growth.
An enterprise, regardless of scale, needs to manage access to information and applications which are scattered, quite often, across a number of internal and external systems. Over time, enterprises must provide controlled access for an increasing number of identities. Identities could be internal and/or external, and one individual can quite often be represented through multiple identities; the key is to ensure both security and data integrity are maintained.
Robust models of IDAM implementation require three essential elements, namely people, processes and products (technologies) in order to manage identities and access to the assets of an enterprise. An assumption in these models is a high level of quality with regards to the data to ensure the IDAM framework functions appropriately.
IDAM components can be classed into four distinct categories, namely:
- authentication
- authorisation
- user management
- central user repository (commonly referred to as 'directory services')
The figure below illustrates the four key components of IDAM, along with capabilities within each component:
Authentication
This covers functionality that enables a user to provide sufficient credentials to gain controlled access to a system / resource / asset. In short, once a user is authenticated (they are who they claim to be), a session is created and referenced throughout the interaction between the user and the end resource until such time as the session is terminated (e.g. via a timeout, logging off, etc.). Very often, authentication takes the form of providing a set of credentials, such as a username and password. The central maintenance of a session allows, for example, the ability to enable single sign-on i.e. no further login is required by the user in order to gain access to multiple resources and assets.
Authorisation
This functionality follows on from authentication, i.e. once you are confirmed as ‘you’ (authentication), this is what are you allowed to do (authorisation). This is typically performed by analysing the access request (such a web Uniform Resource Identifier or URI) against predefined policies stored within the IDAM policy store. Role-based access (RBAC) is key functionality to enable this; it can be overlayed by controls that may additionally look at attributes associated with the user such as groups, user roles, nature of action taken, channels, time, resource types, business rules, security policies, compliance and regulatory requirements etc. to determine the level of access. (Note: an alternative to RBAC is the use of Access Control Lists (ACL), and this, in turn, can be translated to XACML (eXtensible Access Control Markup Language) - but that’s another story.)
User management
User provisioning (and deprovisioning), password management, and role / group management are some of the functions of this area. The focus of this capability within IDAM is primarily administrative in nature and involves the lifecycle of an identity: creation, propagation, maintenance, de-provisioning, etc. Some functionality can be centralised, some can be delegated to end users (or groups), e.g. self-service, password resets. In practice, delegation can often improve accuracy of data within the IDAM primarily due to the end user becoming ‘closer’ to the system; trust between the user and the enterpise is also increased.
Central user repository
Features within this component allow identity information to be exposed to other services. In addition, credential verification to/from other systems becomes available. The central user repository typically exposes an aggregated (logical) view of identities across an enterprise; quite often this depends on what the enterprise wishes to aggregate. Directory services such as Lightweight Directory Access Protocol (LDAP), Active Directory (AD), OpenLDAP (an open source implementation of LDAP) are common meta-directory and virtual directory services which can be used to manage disparate pieces of identity information from a variety of user repositories. In typical implementation, there is a 2-way synchronisation set up to ensure data is always in sync across multiple identity sources.
Identity and access management lifecycle
An IDAM solution in essence manages the lifecycle of an identity in an organisation. A typical lifecycle is illustrated below:
1 - The lifecycle (relationship) begins with the identity being provisioned within the system (1b) e.g. created
2 - The identity is authenticated (i.e. the individual says who they say they are) and authorised (i.e. what are they allowed to access)
3 - The individual (may) be allowed to access Self-Service to manage a given subset of credentials themselves, and may choose to delegate their role (for example, to a personal assistant)
4 - The password associated with the identity may be changed / updated /reset during the course of its life
5 - The access associated with an identity may vary depending on their role(s) within an organisation which may evolve through the lifecycle
6 - Access to resources / assets may (often) be managed through the application of group policies in accordance with compliance and regulatory requirements
7 - As part of managing the lifecycle, reporting and analytics are essential (for example, for security and audit purposes)
8 - If the identity is no longer required (for example, if an individual leaves an organisation), their identity is deprovisioned from the system (8b) thereby ending their relationship
What is Federated IDAM?
In today’s world, there is an increasing need to utilise the same set of credentials to access multiple systems / services / resources. Examples of this are using Google, Microsoft or Facebook credentials (username and password) to log into a variety of websites without needing to create an identity specifically for each website.
An extended capability that IDAM systems introduce is the ability to manage identities and access that span multiple domains (e.g. organisations) and systems in a trusted manner. This is called federated IDAM, and often mitigates against identity replication and security administration in multiple locations. Typically, a group of organisations are able to share identity attributes (based upon security frameworks, trust, standards, policies, etc.) thereby enabling authentication from other users of an organisation and as such granting access to assets.
Federated IDAM delivers the ability for organisations to leverage Single Sign On, interoperability across disparate systems, integration with legacy systems, centralised management of users and identities across multiple locations (domains), reducing security exposure of multiple user credentials, and increasing automation across multiple domains.
Key Benefits of IDAM
The full range of benefits IDAM brings to an organisation are extensive. However, some key technical and business benefits of a correctly implemented solution include (not exclusive):
- enabling a consistent user experience across multiple systems and domains
- giving users quick and secure access to resources they need
- automating joiner and leaver processes and associated access to resources
- reducing the need to remember multiple complex passwords
- making it easier to control access to resources (and automation)
- allowing for easier regulatory compliance and auditing
- enabling centralised controlling and monitoring of users and behaviours
- enabling secure 'Bring / Choose Your Own Device' (BYOD / CYOD)
- allowing for automated (centralised) management of user provisioning and deprovisioning
- centralised management of a user identity across multiple systems (external and internal)
- enable audit, security and access policies to be managed centrally
- consolidating multiple identities and reducing multiple ways to identify one user across an estate or across heterogeneous organisations
- reducing workload due to introduction (and refinement) of role-based administration and group policies
- enhancing physical security
- improving / enabling disaster recovery and business continuity processes
In summary, a well-executed IDAM solution can increase user productivity, drive an enhanced user experience (and, in turn, satisfaction), reduce administrative load (e.g. lowering of calls to HR and Help Desk), minimise manual processes, improve risk and security compliance and enable tracking and management of accountability. All of which will ultimately reduce the costs of running an enterprise.
In my next blog post, we’ll look at the basic functionality of a typical IDAM solution.
I would be interested in hearing of people’s experiences around IDAM, especially with regards to any unusual challenges faced in different sectors and industries.
Follow Jagdeep on Twitter.
13 comments
Comment by pcorpe posted on
Well written and the right level to help demystify what is often thought a difficult subject. In my experience around IDAM, specifically SSO) I often encountered push back around 'keys to the kingdom' i'd be interested to read your thoughts on this related area also?
Comment by Jagdeep posted on
Firstly, thank you for the kind words. It's understandable that many organisations / departments would be reluctant to manage identities centrally (be it in a single IDAM instance, or distributed architecture).
I believe the way to approach this issue is to examine the implications (and user experience) of having multiple identities for multiple systems, vs. a single identity across multiple systems. In relative terms, the latter solution reduces (but doesn't always eliminate) security breaches, ghost accounts, etc., i.e. risk.
Ultimately, it boils down to how sound technology solutions can enable business processes (and vice versa); and how good the architect is in convincing the business / risk owner.
Comment by simonfj posted on
Many thanks Jagdeep,
That's about as a good an overview of IDAM as I've read (although possibly still too complicated for a Minister or Vice Chancellor to comprehend 🙂
As you say, " the way to approach this issue is to examine the implications (and user experience) of having multiple identities for multiple systems, vs. a single identity across multiple systems". So could you do the comparison. We all know that - from an average Joe's perspective - having a single identity is the expectation. Google and co have spoilt us.
With all the talk about "user centric", we're now at the stage where we really do need to address this issue from an inter-networking perspective. e.g. Dan's comment about how - for the IER service to work - "the central GOV.UK process validates with the DWP and then calls an api at the relative local authority - IS "a sign of things to come". It illustrates how the new National network model provides services built around a Local authorities' database(s). http://danblundell.com/2014/06/a-sign-of-things-to-come/
We all know that, from a user's perspective of shared services, the technology is inconsequential. They need somewhere to come from; somewhere to "call" home. http://wayf.dk/en
It's been such a hard one, as a common user/citizen, to be on the outside of networks.gov when watching this move from institutional centric to (inter- institutional) group based provisioning of common services. And sure, we know that everyone will need some education in securing their account(s) and shared information.
So rather than just "looking at the basic functionality of a typical IDAM solution", could we focus on the "single identity across multiple networks" scenario. I'm afraid that, if we don't do this soon, a bunch of network managers in the edu, and gov, space are going to be driven to distraction by their internet-working groups. (There's no challenge in that 🙂
You might like this one. I keep pointing out that in redesigning (inter)network services, .govs always start at Step 3 and Not Step 1. http://blogs.worldbank.org/ic4d/co-creation-of-government-services But what would expect when "they" keep on skipping over the "Discovery" (of how networks are designed) stage?
I always though government was about "we" the "people" agreeing upon the "processes and products" we want to co-design and share. No?
Comment by Jagdeep posted on
Simon
Interesting comments - the holy grail of a single identity across multiple networks can be done, however, policy, legislation, security frameworks, sharing data, etc. has yet to catch up with the technology.
Agree the Discovery piece is essential and is quite often overlooked by (most) enterprises. I'm hoping my future blog posts on the topic will give people the 'push' to start looking at designing, sharing, and crowdsourcing within government.
Comment by Jon Lane posted on
I too found this a concise and accessible outline of IDAM (or IAM as the UK Police Service calls it) but I wonder who, apart from those in the I(D)AM business, is likely to read it. Perhaps it is intended to warm up the audience before PSIIF appears.
In my experience the biggest challenges are not technical. Quality control (compliance) for IAM is costly and falls locally, whereas the risk is usually owned elsewhere. Getting an organisation to sign something before its staff are given access to an information asset may provide at best a limited and short-term level of assurance. When many years ago during a Tube strike the striking fare collectors were replaced by 'honesty boxes', takings dropped to a few percent of normal. In times of public spending restraint how much should an organisation spend on protecting someone else's asset? What should go in the honesty box?
Whilst this issue should not prevent progress with IAM, the importance and difficulty of designing and implementing an effective self-sustaining distributed information assurance scheme should not be underestimated.
Comment by Jagdeep posted on
Jon
Thanks for taking time out to respond to the blog. I'm hoping that more people start talking about IDAM and appreciate what it can do for an enterprise.
In response to your comment on PSIIF: the future blogs should shine some light around how to approach federation (in a network agnostic ; so stay tuned!
When faced with legacy data, much of the challenges (to your point) can be around the quality of the data.
Comment by Peter posted on
Hi Jagdeep,
very nice explanation. You asked for examples from other sectors.
I worked with a telecoms sector client in Holland a couple of years ago where the business owners started to take move some of the lifecycle thinking closer to, well, the actual human lifecycle. The purpose of this modelling was both to help the telecoms client deliver more personalised services and; to enable the customers to retain and understand their history with the service provider.
For telecoms operators this meant that we needed to understand the model of family units and how those family units and relationships changed over time.
To take some examples from the events a family goes through with a child: 1) new child reaches age where they are trusted to authenticate themselves and are authorised to watch the Teletubbies; 2) child reaches university age & moves location from the main family unit, some privileges move with them (e.g. allowed to log on to service from a new location), some don't (e.g. paying the bill); 3) adult leaves a family unit and becomes their own family unit, the individual's history (and in a telecoms operator's case their smartphone!) can now move with them to the new family unit as we modelled the relationships at the beginning.
I can see some cases where elements of this thinking might be relevant to Government.
For example an adult might authorise their child's data to be used on a future version of care.data (i.e. one where the consent is exposed to the citizen); when the child reaches adulthood they would want visibility of what consent has been provided and might choose to revoke that consent as they are now the owners of that level of authorisation and make a different decision to their parents. To perform that revocation they need to know what's already in place.
Or to take an extreme at the opposite end of the real-world lifecycle, LPA (lasting power of attorney) moves in the other direction with some items of authorisation being taken away from one citizen and then passed to another.
I'm sure there's many more use cases, but the starting point is the same - with IDAM and understanding the relationships between different identities.
Given the level of detail of the thinking I'd imagine this is already being thought of within the delegate management line item but it might prove a useful anecdote and type of thinking to explore if not 🙂
Comment by Jagdeep posted on
Interestingly the sectors that are very close to government are telecoms, and of course the financial / banking sectors; highly regulated and deal with high risk and scale.
Love the example you've given; I may steal that for a future posting!
The approach I've taken in many cases is that IDAM solution becomes an enabler for the business. In the initial case is satisfies the needs of the business based upon the tactical and (known) strategic objectives. However, what I have seen is that once the business becomes more aware of the power IDAM brings, it often opens the avenue to do a lot more.
Comment by Jonathan Melvin posted on
Hi Jagdeep
Very interesting...
I was the architect for the Universal Credit IAM solution in the private cloud as well as for the DWP internal IAM solution, and have been instrumental in introducing Identity Federation services within the department.
I think the key role IAM plays when you are moving to SOA/Cloud is really underestimated. It's a core service that everything else needs to build on, so it's good to see you raising its profile.
Please feel free to get in touch if ypou would like to know more about what we have built within DWP.
Thanks
Jon
Comment by Jagdeep posted on
Jonathan
I'd be very interested in seeing what was done with UC. Agree with you on how key IAM is, especially in transformation / migration / merging activities.
Jagdeep
Comment by Shah posted on
Hi Jagdeep
I was wondering if you can help, would you able to advise on external identity management best practices, emphasising on the identity propagation please?
Thanks
Shah
Comment by AnbeSivam posted on
Thanks for the great information. We got lot of information from your article and soon we waiting for the next update..
Comment by vaishalini mathev posted on
Great article. Thanks for your valuable posting..Its was very informative..I am working in Xerrow Technology, a software company