In an enterprise API management platform (or any enterprise platform, really), it’s likely that applications acting on behalf of customers and consumers (B2C), internal business units and employees (B2E), and external organizations and their employees (B2B), are functioning as both API providers and API consumers.
In many cases, applications acting at the behest of consumers will also represent the largest group of API consumers.
Multiple user communities at runtime
To that end, these systems must be able to securely support multiple user communities in a way that does not increase complexity while allowing for scalability, availability, reliability, and all those other words ending in “-ability” that are associated with robust IT systems.
Let’s use an API management platform as our target system of interest. Further, assume there is an internet-facing API gateway that handles the authentication and authorization requirements of the backend API providers — a fairly typical situation.
A user community could be defined in one of two ways:
- Business perspective: a group of users such as all internal employees, users that are part of B2B vendors/suppliers, or customers.
- Technology perspective: users within a single LDAP repository, active directory domain, or similar user repository.
Within an API management solution, the concepts of authentication and authorization come up in several contexts: developert portal (authentication of the developer populations, B2E and B2B), management portal (authentication of API gateway administrators and API developers), and runtime API traffic (the focus of what I’ve been writing much about lately). In this post, the primary use case is working with multiple user communities at runtime when APIs are being invoked.
I’ve used the terms identity provider, OAuth server, federation server, OAuth authorization server, and user repository many times while writing about identity concerns. Sometimes I’m not as disciplined as I should be in my use of these terms (I’ve used “identity provider and “federation server” interchangeably many times, for instance). For this conversation, more discipline is needed. To that end, let’s formally define:
Identity provider: the combination of a federation server and user repository (and possibly other identity stack components needed to enable these two systems to function properly)
Federation server: a service that can issue, validate, and invalidate security tokens. Security tokens are a collection of claims that are usually digitally signed (and, possibly, encrypted) such as SAML2 assertions or JWT tokens
User repository: a system that stores user and group information such an LDAP server or active directory domain
OAuth2 authorization server: a concept that is defined by the OAuth2spec; an identity provider that supports the OAuth2 protocol
OpenID (connect) provider: A concept that is defined by the OIDC spec; an identity provider that supports the OIDC protocol
WS-Trust security token service: A concept that is defined by the WS-Trustspec; an identity provider that supports the WS-Trust protocol
The preferred approach
Most enterprise identity and access management systems would not mix user communities inside the same LDAP repository, active directory domain, or similar user repository. There are security implications to doing this — if the B2C user repository is compromised, you don’t want the employee accounts to be in the same place and vice versa (for starters).
So, ideally, the same technology would be used to build the identity stack that supports these different user communities, but different instances of that technology would be used at the user repository layer. For example, maybe there is a separate active directory domain for each of the B2B, B2C, and B2E user communities. If this suggestion seems fuzzy or questionable, consider an online banking application that a financial institution provides to its customers, or any kind of online account access system. Where is the identity information for those customer accounts stored? Is it in the same LDAP repository as the internal employee accounts? Most of the time, the answer would be no.
If a common product stack can be used across all user communities, then a common federation server can be placed in front of all of them and used by other systems within the security realm to authenticate all users. Most likely, the user repository product vendor has a federation server that can be used. The ideal state of an organization’s identity stack is for a single vendor to be providing all the major components. This approach will often not be possible due to identity stack product constraints, differences in data sets, politics, or history.
The next-best approach would be to have a common federation server that can communicate with multiple user repositories. Systems still have a single “front door” to use for communicating with identity systems; that door is well-defined and well understood. Mixing and matching identity stack components from multiple vendors following a best-of-breed approach generally creates far more problems than it solves.
The next approach, in order of preference, would be to have one master identity provider (for the API gateway’s concerns) that has federation relationships with other identity providers, which can then authenticate (and authorize) the desired user communities. For individual systems, there is still a single point of entry into the identity stack, but each system may have a different front door. The identity space will start to become complex quickly.
If none of those are possible, the next approach would be to use a product that can communicate with multiple LDAP servers or active directory domains at the same time; most products would have out-of-the-box capabilities to do something like this. I know WebSphere Application Server, JBoss EAP, DataPower, and Apigee Edge’s on-premises solution would all be able to do this. There are also LDAP virtualization products that can make a number of LDAP servers appear to be a single repository from the perspective of the LDAP client.
If the target platform does not have out-of-the-box functionality to accomplish the desired approach, something could almost always be written to accomplish the desired behavior. Treat this as a last resort. Using security features provided by a commonly used product is generally a safer approach than writing your own.
Coming up next, I’ll discuss design principles for seamless user authentication.
Image: Flickr Creative Commons/Chilanga Cement