Ten IAM Design Principles

Ground Rules for an Identity Architect In Building an IAM Infrastructure from Ground Up

Identity and Access Management (IAM) done right, could be a key catalyst in building a successful business in the era of digital transformation. IAM addresses the mission-critical needs to ensure appropriate access to resources across increasingly heterogeneous technology environments, and to meet increasingly rigorous compliance requirements. IAM as a security practice is a crucial undertaking for any enterprise. It is increasingly business-aligned, and it requires business skills, not just technical expertise.

There are multiple components in an IAM system: provisioning (or on-boarding), accounts management, identity governance, identification (or authentication), access control (or authorization) and identity federation. IAM is a broad area, so the above components can be further divided. For example, provisioning talks about inbound/outbound provisioning of user accounts, just-in-time provisioning, approval workflows — accounts management talks about privileged accounts management, credential management, users/groups/roles management — identity governance talks about role engineering, identity analytics, segregation of duties, role consolidation, identity delegation, attestation, reporting, self-service, risk management, compliance — authentication talks about multi-factor authentication, adaptive/risk-based authentication — access control talks about access control based on attributes or roles and policies — identity federation talks about single sign on, single log out, session management, attribute sharing. This is never a complete list — and it will keep growing!

However, in this blogpost my intention is not to touch the high-level concepts around IAM, but the low level design principles an IAM architect should know, while building an IAM infrastructure from ground-up.

Immutable Private Identifiers / Mutable Public Identifiers

In any IAM system, a user is identified by one or more identifiers. These can be a username (picked by the user), email address, phone number, insurance policy number, or any identifier, that is unique across the system. The user may pick any one of these to prove himself/herself and access the system. For example, you can login to Facebook either with your email address or the phone number. Also — you can have multiple email addresses and can use any of them. These are your public identifiers — you won’t mind sharing with others.

These public identifiers are mutable. The user should have the option to change them. You should be able to change your phone number, email address or whatever — with zero impact on the system. Some systems/operators recycle email addresses and phone numbers. With that, there can be a case where two or more users get registered in the system with the same email address or the phone number at different times (not at the same time).

This raises the need to have a private identifier which is immutable. The private identifier is a system generated identifier, which is unique across the system and time — never shared with the user — just internal to the system. You will need to have a single place in the system, which maps this private identifier to one or more public identifiers of a given user. Other than this mapping table, users’ public identifiers are never used in the system — for any references — only the private identifier is used. During a login event, the public identifier provided is matched to the corresponding private identifier and that is used to authenticate the user. All the audit logs and analytics are kept against the private identifier. To make the analytics dashboard and reports meaningful, the mapping table can be used to find a more meaningful, human readable identifier of the user only for the display purposes.

Since we maintain all the internal references of a given user using an immutable identifier — changes to the public identifiers will have zero impact in the system.

Decouple Core/Static Personally Identifiable Information (PII) from Transactional Data

According to NIST, Personally Identifiable Information (PII) is ―any information about an individual maintained by an agency, including any information that can be used to distinguish or trace an individual‘s identity (such as name, social security number, date and place of birth, mother‘s maiden name, or biometric records) or any other information that is linked or linkable to an individual (such as medical, educational, financial, and employment information).

Static (or close to static) PIIs are your first name, last name, email, phone number, SSN and so on. The other transactional data, which are linkable to you are the medical records, education/financial records, login patterns, etc. While building the IAM infrastructure the transactional data must be decoupled from the static PIIs — and those can be linked with an autogenerated, immutable system identifier, as explained in the 1st principle.

This separation helps to scale transactional data independently from static PIIs. You can independently pick the storage type, which fits your requirements based on the type of data. Further, this separation addresses data privacy concerns . You do not need to worry about encrypting any transactional data, but the PIIs and the mapping table (which maps the PIIs to an autogenerated, immutable system identifier). When you are asked to delete a user, to be compliant with privacy regulations (like GDPR), you only need to worry about removing static PII and then the corresponding mapping. This will make the corresponding transactional data anonymous.

Decouple Biometrics from Other Personally Identifiable Information (PII)

Aadhaar, a brain-child of the Indian government to secure its residents’ fundamental rights to have an unforgeable identity, is the largest collection of biometric data in the world. It has captured fingerprints and iris of more than 1 billion residents in India. In addition to biometrics, Aadhaar also collects name, date of birth, gender, address, mobile/email (optional) of every resident (no need to be a citizen), and stores those against the corresponding finger prints and iris patterns.

In USA Integrated Automated Fingerprint System (IAFIS) run by the FBI is another large repository of biometrics, which includes fingerprints, facial images, and other physical characteristics, including height, weight, hair, eye color, and even scars and tattoos. The database has more than 70 million criminal records alongside 34 million civil records that law enforcement agents have available on a 24x7x365 basis.

In 2006. A U.S Internal Revenue Service (IRS) employee lost a laptop containing thousands of IRS employee electronic fingerprint records. These fingerprint records were used for electronic access cards into IRS facilities.

There are two common use cases of biometrics: identification and authentication. Biometric identification answers the question “who are you” and usually applies to a situation where an organization needs to identify a person. The organization captures a biometric from that individual and then searches a biometric repository in an attempt to correctly identify the person. This is what happens at the USA air port (and many others). It captures your iris and fingerprints, and tries to identify you against the record they already have in their data store.

Biometric authentication asks the question “can you prove who you are” and is predominantly related to proof of identity in digital scenarios. It does a one to one match to see whether your biometrics matches the identity who you claim to be you. Most of the enterprises use biometrics to authenticate users, as a second factor. One key thing we need to worry here is how you store biometric data. Biometric enrollment and matching are done by a specialized biometric engine. The biometric engine stores biometric templates against the user. Here we have to decouple PII from biometric data — and the easiest way to do that is, get the hash of the immutable private identifier (which is pseudonym) and store it along with the biometric data. Whoever captures the biometric data, will not be able to relate that to the PII of the corresponding user. Even if an attacker got access to both the PII and biometrics data stores, still he/she has to go through all the immutable private identifiers, hash them and then find a match. But remember, we are encrypting the private identifier to PII matching table, so the attacker has to gain access to the corresponding keys too. This will make his/her job very much harder.

Externalize Access Control Rules

Few years back we (WSO2) worked with a large financial institute in USA to build a unified access control platform across the company. They had more than 70 teams internally, and each team had developed their own way of controlling access. Some have used a database to store access control rules in their own schemas, while some have just hardcoded them into the application code. These applications have evolved over many years — and in some teams, no one even knew how things work — and was hesitant to do even a minor change.

This is not an isolated story — I am pretty sure it’s the story of many enterprises. Access control rules are a reflection of business requirements. They should be represented in a way that, the changes in the business requirements can be absorbed into the access control rules with minimal impact/effort. The key fundamental to make it happen is to externalize the access control rules. Once the rules are externalized, you have more control over them — and can evolve independently from the application code. Another important aspect is the separation of duties. In an enterprise its not the application developer who decides on the access control rules — neither the identity architect, but the business itself. It’s not a technical decision, but a business decision. Also — in a production deployment, it’s not the developers or the architects who configure access control rules, but an IAM admin or a system admin. Externalizing rules, helps us get there much smoothly.

Once the rules are externalized, you must think what’s the best way to represent them — and how they are enforced. As an identity architect you need to build an architecture for policy administration, policy enforcement, policy evaluation and policy storage. If you plan to build this from scratch I would recommend having a look at XACML. XACML presents a reference architecture, a policy language and a request/response protocol. The XACML reference architecture defines a policy administration point (PAP), policy decision point (PAP), policy enforcement point (PEP), policy information point (PIP) and the interactions between them.

The policy language in XACML is XML based. It’s quite rich in terms of what it can do — but not fairly straight forward. Few years back (may be seven/eight) I developed the very first version of XACML support to the open source WSO2 Identity Sever. Over the years it improved a lot to what it is today — but if i recall, the feedback we got to its very fist version was not all good. Most people didn’t like writing XACML policies in raw XML. Some thought it’s like writing a program in assembly — which was little exaggerating though. Anyhow we took the feedback seriously and improved the XACML support in WSO2 Identity Server over last seven/eight years, where even people who have not heard of XACML can use it. Anyway, the bottom line is — if you decide to go ahead with XACML as the policy language, you need to worry about the tooling support around it.

The XACML request/response model can be either XML based or JSON based — and the interaction between the PEP and PDP can be standardized via a REST API. Then again, first you need to worry about access control requirements — and then decide how to represent those as policies (or whatever). Check our 7th design principle here. Prefer standards always — but you do not need to use it just because it is a standard — even if it’s an overkill to address your requirements. Also — check what else around. AWS has developed their own JSON-based policy language to control access to AWS resources. Here is an overview of AWS policies.

If you are going to build your own policy language (much like what AWS has), you need to clearly identify and differentiate rules from data. This may not be clear without an example. Let’s say you need to have a policy, which says, a doctor can only view a record of a patient, only if that patient belongs to him/her. You should not put the name of the doctor — and all the other patient names under him/her, into the policy itself. These are the data, which dynamically changes. You just need to have sort of a reference in your policy — and provide some policy information points (PIPs) to interpret that, fetch the data and feed the data into the policy engine. Once again, there is a cost of building a policy engine — so you can also think of developing your own DSL (domain specific language) and write a translator to run it on a proven XACML engine or even on a rules engine.

Low Trust Planes Have No Write Access

Each component in a network has a trust level. The key components in an IAM deployment includes the identity provider (IdP), identity store (ldap/database), metadata/policy store, a gateway (policy enforcement point) and finally the service providers. Each of these components or some of these components can be in different trust planes.

It’s a not a must that, the identity provider and the identity store, in the same trust plane. This can be the case in a larger enterprise, where you have multiple identity providers. In one of the largest communication and network infrastructure services provider in USA, we worked with, had a core identity provider deployed over their corporate identity store. Both the identity provider and the identity store, in that case were deployed on the same trust plane. This identity provider is the back-born of their corporate identity infrastructure — the single source of truth — and is managed by the corporate IT team.

The project we worked with was for one of it’s departments — where the identity provider was deployed in a different trust plane. All the service providers/applications deployed under this department only trusted its own identity provider. The identity provider deployed at the department level (let’s say the local identity provider) was on a lower trust plane than of the corporate identity provider — and also the corporate identity store. So it cannot have a direct write access to the identity provider on the high trust plane. The communication between the two identity providers were facilitated through SAML 2.0 Web SSO. All the additional user attributes required for the service providers/applications were captured centrally at the local identity provider and were JIT provisioned. Then again, even within the same department, the local identity provider and the service providers were in different trust planes. The service providers were only given readonly access to the identity provider’s APIs.

Building and designing an IAM infrastructure on different trust planes helps decentralizing responsibilities and the ownership, based on the level of trust.

Decouple B2C from B2E and B2B

In B2E IAM, on-boarding is a responsibility of the employer, while in B2C mostly it’s self on-boarding. In other words, for employees, its the HR department who initiates the employee on-boarding process and remains the owner of the user accounts, while for customers — in most of the cases the on-boarding happens via self registration. It can be a completely new customer or an existing customer who now wants to use company’s online services. Let me give you few examples for the latter.

• Some time back we worked with a popular life insurance provider in USA. The insurance agents sell the insurance policies — and then to do the payments and claims online the customer has to register via the company’s web site. The customer registration form asks a minimal set of details like the policy number, social security number, name and the date of birth — and the user provided information will be automatically validated against the user data already recorded in the system (after the original policy being sold).
• Another company we worked with, who sells medical equipment to individuals and medical institutes, let them register via the company web site to consume online services. As in the case of the previous example, the medical equipment are sold by sales agents — and all the customer data are recorded in Salesforce. When a customer decides to register online — the data entered by the customer is verified against the data already recorded in Salesforce.
• Recently we worked with a company in the west coast, who’s building a virtualized data center at the enterprise level. They do follow the same model as explained in the previous example. They too maintain customer records in the Salesforce first, at the point of the sale — and then later the customer can register via the company’s online portal by providing the same information recorded before in Salesforce.

There can be tons of examples and variations in models used in customer on-boarding. In addition to the above scenarios, there are multiple companies that we have worked with who open up the user registration for new customers. Most of these companies let customer registration via a known public identity provider. This vastly reduces the initial barrier for registration — and there are multiple studies which confirm the huge success rate in user registration after integrating with known public identity providers (Facebook, Google, Microsoft Live).

B2E/B2B IAM is also collectively known as workforce IAM. The workforce IAM looks inward. The workforce IAM focuses on B2E (business-to-employee) and B2B (business-to-business) interactions. The goal of workforce IAM is to reduce the risk and cost associated with on-boarding and off-boarding new employees, partners and suppliers, while the purpose of customer IAM (or B2C) is to help drive revenue growth by leveraging identity data to acquire and retain customers.

The key challenge in workforce IAM is to break identity silos in the enterprise and build a unified identity platform, which will result in much improved productivity, security, governance, oversight, compliance and monitoring. Ultimately this will reduce both the risk and cost associated with all the B2E and B2B interactions. Recently we worked with a large analytics firm in USA to help them migrate from their current IAM system — which is quite ad hoc in nature into an optimized model. The key challenge there was to come up with a model to build a unified identity model across all the applications. They had more than 30 identity stores used by multiple applications — and the same user is duplicated in each identity store with no correlation handle.

What I would like to highlight here is, B2C, B2E and B2B IAM models have their own design goals and challenges. There is no all-in-one solution. Also — you need to build these IAM models, independent from each other. Should not share the same identity store and the same identity provider between both the employees and customers. If you have applications that require access from both the customers and employees, you need to think about a federated model.

Persistent Pseudonyms for Attribute Sharing

One key responsibility of an identity provider, running in an IAM infrastructure is to act as the single source of truth. All the other components in the corporate network (and beyond) trust the assertions issued by the identity provider. These assertions can be authentication assertions, attribute assertions or authorization assertions. Assertions are bound to the authenticated subject. What is the subject identifier the identity provider should use here, with respect to the authenticated user?

I would like to request you to revisit our very first principle, private immutable identifiers/public mutable identifiers. The public mutable identifiers — as the name suggests — are mutable. If you use one of those as the subject identifier, then the service provider will find it hard to correlate the user after a change in that attribute at the identity provider end. How about the private immutable identifier (as the subject identifier)? Once again as the name suggests it is supposed to be private — and should not be shared outside.

The approach I suggest is to use a persistent pseudonym by user, by service provider. Each user will have a different pseudonym per each service provider — and is mapped to its private immutable identifier at the identity provider. Each service provider can use this pseudonym as a correlation handle. Further this addresses some privacy concerns too. If you share the same identifier between multiple service providers, then those service providers together can discover your behavioral/access patterns. This may be not be a key concern in a corporate environment — but if you are building a public identity provider, it will.

Standards Rule!. Feel Free to Fix It — But Do Not Break!

In a keynote at the European Identity Conference 2015, Ian Glazer who is the Senior Director, Identity at Salesforce, also a well-respected fellow in the identity domain did an awesome speech under the topic, The TCP/IP Moment in Identity. What he highlighted there was, just how the TCP/IP stack got matured — no Identity product today will gain any competitive advantage just by supporting open identity standards. That’s given and expected by any identity product. If you build an identity product with no support for open standards — you are born dead.

The standards are not born alone. There are many committees under the standard bodies such as W3C, IETF, OpenID Foundation, OASIS, Kantara Initiative and many more, working day and night with absolutely amazing people, discussing the problems in the identity space, building solutions and standardizing those. Once you define your problem, you should spend some time and see how the identity standards out there, help you in building a solution. Once again, do not get driven by the standards, but by your own problem statement. There is always room for an improvement. If you do not find your problem being addressed properly, don’t be hesitant to build the solution by fixing it. Then if you would like, you can take your solution to a standard body and see how it can made its way to a standard. That’s how the identity standards evolved over the years.

Let me highlight here some of the key standards used in the identity space. For identity federation and single sign on, SAML 2.0 Web SSO, OpenID Connect, WS-Federation are the prominent standards. SAML as a standard still rules — but then again if you look at the last couple of years most of the new developments were using OpenID Connect. OpenID Connect is a standard built on top of OAuth 2.0. For fine-grained access control, only standard out there is XACML. We already discussed about XACML. For provisioning, SCIM is the prominent standard. OAuth 2.0 and multiple profiles building around it, are the key standards in securing APIs — and also in generally for access delegation. FAPI (financial APIs) working group under OpenID Foundation is working on building a set of standards around OAuth 2.0, mostly targeting financial applications. UMA (User Managed Access) is another prominent standard being developed under the Kantara Initiative. UMA tries to build a rich, highly decoupled ecosystem around access delegation. Once again UMA is built on top of OAuth 2.0. The work of JOSE working group under IETF, is another area you should pay attention to. Multiple standards like, JWS (JSON Web Signature), JWE (JSON Web Encryption), JWK (JSON Web Key) are being developed under this working group.

Self-Expressive Credentials

This is pretty basic — even to list it down here. But then again there are multiples aspects in it most people rarely worry about. How do credentials express themselves? I have seen people building systems without worrying about this fact, and fall into a trap later when they have to upgrade the system to support a much secure hashing algorithm.

Securing user credentials is one of the key aspects in any IAM infrastructure. These credentials can be just passwords, or any kind of keys. For example, in OAuth 2.0, we need to worry about protecting client secrets, access tokens and refresh tokens. There are two types of credentials that you store in an IAM infrastructure. The ones that you own (or issue) — and the ones that you use. I assume the first type is pretty obvious, which includes passwords and the OAuth keys issued by you. The credentials that you store to access third party systems fall into the second category. For example the API keys to access Facebook — to enable login with Facebook, or the API keys to access the Salesforce/Google Apps APIs to provision users.

The first type of credentials can be secured with a salted hash — and the second type should be secured with encryption. What I meant by, let credentials speak is, let them be self expressive. In other words, when you hash a credential — bind the hashing algorithm into the hashed credentials itself. When you try to validate the credentials, the credentials itself will be self expressive, just by looking at it, you know how it is hashed.

What is the benefit of this approach? Let’s say you only have a system level hashing algorithm (this anyway you need to have). All your user passwords are hashed with the system level hashing algorithm. Now let’s say you need to change the hashing algorithm to a much secure one. For new users it won’t be an issue — all the new credentials will be stored under the new hashing algorithm — so as the validation. How about the existing users? All the credential verification with respect to the existing users will fail— and there is no straightforward way of doing a bulk migration. This is the trap you fall into with this approach. If you make the credentials self expressive, then you know how to validate each of them independently. Also with this approach if you find any credentials, that are stored against a hashing algorithm, which differs from the system setting, then you can rehash with the new one and update the system at the point of validation.

For any hashed data, the hashing algorithm is the most important thing. In 2012, LinkedIn was compromised and had password data stolen. At the time, LinkedIn was using the MD5 hashing algorithm for password storage. This was a dangerously bad idea because flaws had been discovered in MD5 as early as 1996 and even its own author stopped recommended using it as of 2005. The first go-to algorithm for password storage is PBKDF2 NIST standard key derivation function. This is one-way and can be configured to process relatively slowly — on purpose. Why do we want to make it slow on purpose? GPU cracking rigs and other supercomputing resources can attempt many billions of hashes per second. When using a purposely slow algorithm with proper configuration settings, those billions of attempts per second become mere thousands of attempts per second on the same hardware.

Privilege Accounts are a Different Species

A privileged account is how administrators login in to servers, switches, firewalls, routers, database servers, and the many applications they must manage. In an IAM infrastructure there are multiple occasions where privileged accounts are used. The database credentials, identity store credentials (Active Directory), IAM admin credentials (possibly accessing a web-based management console to perform IAM admin functions) and also the other third party system/service accounts (access IAM APIs to perform administrative functions) all fall under the category of privileged accounts.

Forrester estimates that 80% of security breaches involve privileged credentials. It’s quite understandable that after an intruder gains access to the employees’ devices, they try to snoop the network and install a key-logger to get higher privilege credentials (such as root or administrator). Privileged credentials provide greater scope for stealing data en masse than individual accounts do. With privileged credentials, attackers can dump the entire database, bypass network traffic limitation, delete logs to hide their activity, and exfiltrate data easier.

Privileged Identity Management (PIM) is key area in IAM and there are specialized vendors who build products to support PIM. While building any serious IAM infrastructure you need to worry about how your system integrates with PIM products. It is also required to have a PIM system in place to comply with industry mandates such as SOX, PCI-DSS, HIPAA, FISMA,BASEL III and many others.

Summary

The objective of this blog post is to cover the key fundamentals that would be helpful to an identity architect, building an IAM infrastructure from ground-up. The list covered here is no means inclusive. I would like to invite you to share your experience and thoughts in the comments section below to build a constructive discussion.

Prabath Siriwardena