From federation to fabric: IAM’s evolution

In the modern day, we’ve come to expect that our various applications can share our identity information with one another. Most of our core systems federate seamlessly and bi-directionally. This means that you can quite easily register and log in to a given service with the user account from another service or even invert that process (technically possible, not always advisable). But what is the next step in our evolution towards greater interoperability between our applications, services and systems?

Identity and access management: A long evolution

Identity and access management (IAM) has evolved into a sprawling field of separate but interrelated processes. 

Even before the recent pandemic, both the users of our tech stacks and the servers that host their applications were becoming more and more dispersed and scattered. The pandemic only served to hyper-accelerate that trend. 

As Gartner’s Cybersecurity Chief of Research, Mary Ruddy stated recently, “Digital security is reliant on identity whether we want it to be or not. In a world where users can be anywhere and applications are increasingly distributed across datacenters in the multi-cloud… identity and access is the control plane.”

Add to this the fact that most cybersecurity functions score about 2.5 on Gartner’s five-point maturity scale and we see the usual tech dynamic of convenience forging ahead as security struggles to keep pace. 

To see how these patches of user databases and applications can be stitched together into a united whole and allow for risk and context-based access control across the board, we will explore how identity and access interoperability have evolved from federation standards and protocols until now and how this is evolving forward into a cohesive identity fabric. 

It’s time to learn from the past, evaluate the present and, of course, prepare for the future of IAM.

Past: A history of federation

Dropping into the timeline around the year 1995 lands us in a time when the green shoots of identity interoperability were just starting to show.  

Twelve years and several threads of directory (or user database) research and development culminated around this time, with the emergence of the Lightweight Directory Access Protocol (LDAP) – version 3. This standard became the basis for the Netscape Directory Server in 1996, OpenLDAP in 1998, and the now ubiquitous Microsoft Active Directory in 2000. 

The standard was initially optimized for read rather than write operations and was designed to allow client apps with very limited computing available (less than 16MB RAM and 100 MHz CPU) to query and authenticate users quickly. By achieving this low-overhead functionality, LDAP quickly became the de facto authentication protocol for internet services. 

Inside the integrated Microsoft (MS) estate, Active Directory authenticated credentials against an LDAP directory and granted access to the operating system (OS) and any applications to which a user was entitled. 

Outside the MS estate, single sign-on had to be achieved by reverse proxy servers that authenticated users (usually via LDAP) in a holding pen before redirecting them into the various systems to which they were entitled. Under the hood, this approach tended to combine LDAP, 302 HTTP redirects, and identity information injected into HTTP headers, with cookies used as session tokens. This Web Access Management (WAM) paradigm was effective but somewhat crude and varied greatly from app to app. 

Now that a relatively universal authentication protocol was established, the lack of a standardized way of landing users post-authentication into applications along with user, session or account attributes was in evidence. In addition to this, session tokens based on cookies were only viable intra-domain and not inter-domain. Authorization was even clunkier, with specific endpoints/URLs within applications needing to be HTTP redirected to the auth server, which, in turn, would check against LDAP attributes before allowing the user to see a page or take action. 

SAML 2.0: A circle of trust

By the mid-2000s, threads of research and development (R&D) were coming to fruition, with WS Federation,  Liberty Alliance’s ID-FF 1.1, and the Organization for the Advancement of Structured Information Services (OASIS) Security Assertion Markup Language (SAML) 1.1 being the standout candidates. The latter two, along with Shibolleth, converged and OASIS ratified SAML 2.0 in March 2005.

The concept was to create a circle of trust between a user, a directory, and an application. Administrators on both the application and directory sides could exchange signing certificates to create trust between their two systems.

In an identity-provider-initiated flow, directories can redirect authenticated users into an application from an application launchpad. However, in a service-provider-initiated flow, users can attempt to log in to applications and (typically) be recognized by their email domain and redirected to their home directory to be authenticated there before being redirected back to the app. 

In both cases, users land into an application with a SAML assertion, a piece of XML data that encapsulates their identity data, any other custom fields or attributes like account balance or shopping cart contents, and the x.509 signing certificate mentioned above. 

SAML authorization is most commonly performed by landing a user into an application with roles already defined on the application side, such as standard, manager, developer or administrator. This typically means a user’s allowed/disallowed pages or actions are tied to their role type. 

In SAML 2.0, we finally had an identity federation technology, a standardized way for users from one directory to access multiple applications and (best of all) across different network domains. 

In identity federation, one system plays the role of a directory or user database, and the other system plays the role of the application being accessed, even if both systems are commonly thought of as apps. 

Below are diagrams showing how two of the most widely used enterprise systems that support SAML could federate one way or the other. In one, Salesforce acts as the identity provider (directory or user database) for accessing Azure, and in the other scenario, the roles are reversed. The point is to illustrate how the federation uses combinations of LDAP and SAML to allow users to access a service with their accounts from another service.

Scenario 1

 

Key:

1. The user chooses an option to sign in to Azure with their Salesforce account.
2. Azure redirects the user to Salesforce for authentication.
3. The user’s credentials are authenticated via LDAP against Salesforce’s directory.
4. Salesforce sends a signed SAML assertion containing the user’s data to Azure to log them in.

Scenario 2

 

Key:

1. The user chooses an option to sign in to Salesforce with their Azure account.
2. Salesforce redirects the user to Azure for authentication.
3. The user’s credentials are authenticated via LDAP against Azure’s directory.
4. Azure sends a signed SAML assertion containing the user’s data to Salesforce to log them in.

The consumer computing revolution

Beyond the enterprise, the release of iOS in 2007 and Android in 2008 saw an explosion in consumer computing. 

Consider this statistic: in 2010, 37 percent of households owned a computer, but by 2014, 37 percent of individuals owned a smartphone. Across the two mobile OS in 2012 alone, roughly 1.3 billion new apps were shipped, with about 35 billion app downloads distributed across these new apps.

Client-side applications became extremely lightweight — mere viewing and input panes — with the vast majority of the logic, data, and computing residing on the server and injected in over the internet.

The number of application programming interfaces (APIs) mushroomed to cater to a population that increasingly demanded their apps and services be able to share their data with one another, particularly to allow for subscribing to a service with their accounts from another service.

R&D into a consumer computing open identity standard had been underway at Twitter and Google since about 2006 to 2007. During these conversations, experts realized that a similar need existed for an open standard for API access delegation. How could one application grant a certain amount of access to another without sharing credentials (which, in any case, would give total access)?

As Eran Hammer-Lahav explains in his guide to OAuth, “Many luxury cars today come with a valet key. It is a special key you give the parking attendant and, unlike your regular key, will not allow the car to drive more than a mile or two… Regardless of what restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key while using your regular key to unlock everything.”

How does OAuth work?

OAuth was the framework that emerged to solve this problem. It allows users to share data without sharing passwords.

Let’s take a look at what happens on the backend when a photo printing service allows you to share your pictures from an online storage platform instead of requiring you to upload them from your local machine.

Below is an attempt to explain an OAuth authorization flow as simply as possible for a nine-step process. Formal terms for the various parties involved are bracketed. In this process, a user can share images from their Dropbox account with Photobox, an online photograph printing and delivery service. Like in the SAML relationships described earlier, admins from both platforms must establish a backend trust based on a client ID and client secret (instead of an x.509 certificate as in SAML) — this can be thought of as Photobox’s username and password with Dropbox. It describes a scenario where a third-party authorization service (often an IAM platform) is leveraged, but many websites or services may implement their own authorization service.

1. A user opts to share data from one service (data holder) with another service (data requester). The data requester contacts the data holder with a client ID and client secret.
2. Data-holding service redirects the request to an authorization service.
3. The authorization service contacts the user’s browser to have them log in and/or provide consent to share data with the data requester as required. 
4. The user logs in and/or provides consent to share data, often specifying what data can or cannot be shared (scopes).
5. The authorizer redirects back to the data requester with an authorization token.
6. The data requester contacts the authorizer on the backend (not via the user’s browser) with the authorization token plus client ID and client secret.
7. The authorizer responds with an access token specifying the scope of what may or may not be accessed.
8. The data requester sends an access token to the data holder.
9. The data holder responds to the data requester with the scoped content.

SAML authorized users “in advance” by landing users into applications with a specified role, and those applications defined what different roles could or couldn’t do. OAuth allows for much more fine-grained authorization on a per-page or per-action basis. This reflects an expansion from role-based access to a more resource-based access control mentality that emphasizes the thing being accessed over who is doing the accessing.

Registration and authentication

But what about registering and authenticating users? Most people think of OpenID Connect (OIDC) as an extension of OAuth, which is optimized for authentication instead of authorization. OAuth itself, incidentally, appears less keen on this characterization:

“OAuth is not an OpenID extension and at the specification level, shares only a few things with OpenID — some common authors and the fact both are open specification in the realm of authentication and access control.”

While they are used for different purposes — OAuth to authorize, OIDC to authenticate — the fact is that an OIDC flow is an OAuth flow with the addition of identity tokens to the authorization and access tokens.

Let’s look at the flow behind the scenes in a scenario like the one below, where you can register or log in to Airbnb with your Apple ID.

 

1. The user opts to log in to Airbnb with Apple ID.
2. Airbnb sends a request to the Apple ID service containing Airbnb’s client ID and client secret configured by both platform admins. 
3. The user authenticates against Apple ID’s directory.
4. Apple ID sends an encoded identity JSON Web Token (JWT) to Airbnb that contains the user’s information. Airbnb can decode Apple’s identity token by using a public key. The user’s session is created.

Unlike the OAuth flow described earlier, the resource server/data holder and the authentication service are one and the same organization, with AppleID both holding the data and authorizing its sharing. Alternatively, a third-party IAM platform could be implemented to query an OpenID provider and authenticate against it.

The JSON Web Token

The emergence of the JSON Web Token (JWT) around 2013 was a crucial element in the evolution of identity federation and modern authentication. Essentially a JSON data format with added security features, it defined a secure and standardized format for signing, encrypting, decrypting, and transmitting identity data across domains.

JWTs consist of three parts:

1. Header: Contains fields for type (which is JWT) and the cryptographic algorithm used in the signature in section three (often RSA or SHA256). If services have opted to encrypt as well as sign the JWT, the encryption algorithm will also be specified here.
2. Payload: Contains the actual user information being transmitted in key: value pairs.
3. Signature: This is where the content of the header and payload has the cryptographic algorithm specified in the header applied to ensure its integrity and authenticity. 

This is a sample JWT, encoded and decoded with a header specifying a JWT and the signing algorithm used, a payload specifying a unique ID, a name, and whether the user is an admin, and finally, a signature section.

It’s worth noting that while OAuth implementations may issue authorization and/or access tokens in XML, simple JSON, or JWT formats, OpenID Connect mandates the use of JWTs for identity tokens to ensure the authenticity and integrity of personally identifiable information.

This wraps up the main identity federation and access protocols and frameworks. It’s useful to think in terms of a user that wants to ‘come from’ some directory and ‘go to’ some application in most cases. The terms used in the different protocols vary but can be mapped reasonably well like this:

 

System for Cross-Domain Identity Management (SCIM)

Outside of access management, one more crucial IAM protocol is worth mentioning. The System for Cross-Domain Identity Management (SCIM) is the most common protocol for identity management. It is used to execute remote creation (provisioning), updating and deletion of users and groups from within an identity platform. It is also extremely useful for allowing developers to build out self-service user journeys such as address/phone/payment updating or password resets. Essentially a REST API optimized for identity governance, it has become a relatively universal standard, with most large cloud platforms now having SCIM endpoints that will accept HTTP POST and PUT requests.

Figure: Typical remote user-create SCIM API call

Present day: The state of identity and access management

The long march from LDAP to SAML, OAuth, OIDC and SCIM has seen profound evolution and interoperability in IAM. These protocols have done much to allow systems to lean on one another to authenticate users, authorize the sharing of resources, or agree on standardized ways to lift and shift user data.

As IBM’s Bob Kalka likes to say, “Identity and access is an amorphous blob that touches on everything.” There are several separate but related processes that IAM admins, engineers and architects must be concerned with. The tooling developed by vendors has grown up to service these processes. Let’s look at the main ones:

1. Orchestrate user journeys across applications, directories, and third-party services (like identity proofers) from the user interface (UI) backward down the stack. The web redirect is still one of the most basic units of work, as users get bounced around between systems to execute user journeys that call on multiple systems. This usually demands that IAM engineers understand front-end web/mobile development and vice versa. 

2. Consume identities from or sync and provision (CRUD — create, read, update, delete) identities into any number of identity sources of varying kinds.

3. Control the provisioning, updating, and deletion of your joiners, movers, and leavers on the application side.

4. Authenticate users into any number of target applications of varying kinds. Things are easier when applications have been built to modern federation specifications like SAML or OpenID Connect. These can then receive identity and account data from directories in a standardized way. However, many organizations do not have the resources to invest in modernizing the applications that do not support these modern protocols. Landing users into these applications securely while populating them with their identity or other account information as necessary (session creation) can be especially challenging.

5. Perform adaptive or context-based access control across the estate. Access policies can be based on static conditional rules related to location, device, user/group attributes, or the pages or actions being accessed. Access management is increasingly leveraging machine-learning algorithms that profile usage patterns and increase their risk score when significant divergence from these patterns is detected. Once these ‘ifs’ are defined, admins can define ‘thens’ that might range from allow, multi-factor authentication (MFA), extra MFA, or block sessions, depending on the riskiness of the user’s session.

6. Integrate IAM with the organization’s Security Operations (SecOps). Most cybersecurity organizations scored 50 percent on a recent Gartner five-point maturity scale for IAM. SecOps and IAM are indeed quite distinct specializations, but the low level of interoperability is surprising. At the very least, it should be taken for granted that your security information and event management (SIEM) is consuming IAM logs. This convergence of disciplines is dubbed identity threat detection and response (ITDR).

7. Control access to privileged systems like server operating systems and root accounts of cloud service providers. These privileged access management (PAM) systems should, at a minimum, vault credentials to these systems. More advanced practices include approval requests, session recording, or credential heartbeats to detect whether credentials have been altered.

This is the point at which IAM stands today: a proliferation of tools, processes, and integrations. To add to that complexity, most organizations’ IAM terrains are fragmented, at least along workforce and consumer lines. There is just as often further fragmentation on a per-business unit, per-product offering, or per-budget basis.

Where can our efforts to further unify this control plane lead us?

Looking Ahead: The identity fabric

Gartner refers to an identity fabric as “a system of systems composed of a blend of modular IAM tools.”

As a discipline, IAM is at a point somewhat reminiscent of the world of SecOps circa 2016. At that time, there were several distinct but interrelated subdisciplines within the Security Operations Centre (SOC). Detection, investigation, and response were perhaps the three main process specializations, as well as product categories. Endpoint detection and response, threat intelligence, and threat hunting were and are swim lanes unto themselves. It was in this context that the need for orchestration processes and SOAR tooling emerged to stitch all of this together.

Given the security ramifications at stake, the evolution toward greater cohesion in IAM must be maintained. This more unified approach is what underpins the identity fabric mentality.

If it is a composable fabric of tools woven together, the orchestration layer is the stitching that weaves that fabric together. It is important to think of orchestration as both a work process and a tool. 

Therefore, an identity fabric constitutes any and all of the seven work processes an organization needs to carry out its use cases — plus an orchestration process. This is how the “centralized control and decentralized enablement” discussed by Gartner is achieved.

IBM tooling across the 7 IAM work processes

IBM’s mission within the IAM space is to allow organizations to connect any user to any resource.

We have, for some time, had the greatest breadth of IAM tools under one roof. We were also the first to offer a single platform that supported both runtime (access management) and administrative (identity governance) workloads in a single product. This product, Verify SaaS, also has the distinction of still being the only platform equally optimized for both workforce and consumer workloads. 

That we have tooling across all seven process categories is a unique differentiator. That we offer a single platform that straddles five of these seven processes is even more unique.

Examining the seven work processes, here is a brief holistic outline of the toolbox:

1. Orchestration

Our new orchestration engine is now available as part of Verify SaaS. It allows you to easily build user journey UIs and use cases in a low-code/no-code environment. On the back end, you can orchestrate directories and applications of all kinds and easily integrate with third-party fraud, risk or identity-proofing tools.

2. Directory integration and federation

IBM’s on-premise directory is the first on the market to support containerized deployments. Virtual Directory functionality allows the consumption of identities from heterogeneous identity sources to present target systems with a single authentication interface. Directory Integrator boasts an unrivaled number of connectors and parsers to read identity records from systems or databases and write them into other required directories. 

3. Identity governance

IBM offers powerful and customizable identity governance platforms in SaaS or software form, as well as out-of-the-box connectors for all the major enterprise applications, along with host adaptors for provisioning into infrastructure operating systems. Additional modules are available for entitlement discovery, separation of duty analysis, compliance reporting, and role mining and optimization.

4. Modern authentication

IBM offers runtime access management platforms available as SaaS or software. Both support SAML and OpenID Connect. The software platform’s heritage is in web access management, so the base module is a reverse proxy server for pre-federation target apps. 

The IBM Application Gateway (IAG) is a special gem in our IAM toolbox. A novel combination of old and new technologies, it allows you to serve a lightweight reverse proxy out of a container. Users are authenticated in via OIDC and out into the target application via reverse proxy. It can front an application that doesn’t support federation. It can also be used to enforce access policies within your custom application based on URL paths, hostnames and HTTP methods. Available at no extra cost with any Verify Access or Verify SaaS entitlement, it is now available as a standalone component. The Application Gateway allows you to modernize how your custom app is consumed without needing to invest in the modernization of the app itself. 

 

 

5. Adaptive access

Trusteer is IBM’s fraud detection solution. It ingests over 200 data criteria to risk score user behaviour, such as time, typing, mouse patterns, browser or OS information, and virtual machine (VM) detection. Available to deploy standalone within your front-end applications, Verify Access and Verify SaaS can also leverage Trusteer’s machine learning algorithm to risk score a user session at authentication time. 

6. Identity threat detection and response

In addition to the Verify products’ native threat detection capabilities, they can easily integrate with the IBM X-Force threat intelligence platform and other third-party risk services. This data can be leveraged to immediately reject common or compromised credentials or requests from known malicious IP addresses. 

7. Privileged access management

To round out the IAM toolbox, Verify Privilege provides credential vaulting and heartbeat, session launchers, and session recording for mission-critical infrastructure operating systems, databases and systems.

Embracing cohesive IAM solutions

In the spirit of composability, IBM offers virtually every kind of IAM tool you could need, along with the orchestration engine that can stitch your identity estate into a cohesive fabric. They are all designed to interoperate with other directories, applications, access managers, or identity governors you may currently have deployed. The unique proposition is that we can provide what is missing, whatever that may be.

Where identity and access have always tended to have been a layer of abstraction within applications or operating systems, the identity fabric paradigm is about decoupling identity and access from applications, directories, and operating systems. The aspiration is for identity to graduate to a layer that floats above systems rather than remain a layer that is embedded within them.

To leave aside tooling and technologies for the final word, implementing the available tooling that facilitates an identity fabric will not automatically make it a reality. Currently, a solution architect is almost as likely as not to believe each solution requires its own directory or access manager, much like most solutions must be underpinned by their own databases. In this context, is it any surprise that IAM processes are so siloed and fragmented?

Contact your in-country technical specialist to book a free identity fabric workshop and discuss how you can evolve your IAM environment into a cohesive security control plane.

Explore IBM IAM solutions

The post From federation to fabric: IAM’s evolution appeared first on Security Intelligence.