In my six years at Ping Identity, I've had a lot of identity architecture discussions with everyone from CISOs to security teams, to complete newbies who are starting from scratch. The context of the conversation has changed over the last six years, but the terminology hasn't. The terminology we use to describe identity architecture needs a big overhaul. I think this fact is holding us back as an industry.
Six years ago, we were solving a simpler problem. Identities inside the network perimeter needed to be bridged into somebody else's network perimeter. The goal was to create a secure envelope to send with a user that announces the identity of that user to the remote network perimeter in a secure way. The assumption was that one entity was providing identity information and the other was relying on that identity information. Thus the terms "IDP" and "RP" (aka "SP" or service provider) were coined.
Things are more complex now. We've moved on from a single-domain, browser-centric form of communication. Cross-domain communication is now the norm, not the exception. Users now interact across those domains, via not only the browser but also via native code that runs in the background and acts independently. We're authenticating users with multiple factors, and users are bouncing to many different web domains in the course of an initial authentication. And while it is impressive just how many edge cases the authors of SAML thought up, it is not the only protocol out there, OpenID Connect and OAuth are growing in adoption, and have a whole different lexicon that does not fit the "user present" browser scenario.
Trying to explain these much more complex architectures with simple IDP/RP notation just doesn't work. It's like trying to explain the layout of a bathroom starting with the thread size of the steel pipe fittings that deliver the water to the appliances. Instead of using outdated identity plumbing jargon, we Identity Architects need a new way to explain our identity infrastructures in terms of authorities, resources, services, and domain boundaries.
When describing modern architectures, we should assume that all transactions in a federated access management flow involve providing and relying. Maybe that flow is natively standards-enabled. Maybe a bridge is required to translate. Whatever mechanism is used, it's just that: a mechanism.
What if we could start talking about who is responsible in an identity architecture? If five different authentication services might be invoked in a transaction, then who is deciding which authentication services get invoked when? That entity is more than just an authentication service, although it may take all those different authentication and data sources and produce an identity assertion that looks like a simple authentication service to everyone else. I think a true identity architecture needs to designate an authentication authority for a given frame of reference, which has a different responsibility than a simple authentication service.
The same thing applies on the other side of an identity transaction. Not all organizations have the need to protect applications themselves. But those who do are now having to think about holistic protection regimes that go way beyond validating an assertion, setting a session cookie and walking away. Modern access security is about protecting a disparate set of corporate resources as close to continuously as technology will allow.
What entity is responsible for ensuring that deep policy and security evaluation is applied at the time of resource access, regardless of whether that resource is a native app on a mobile phone, a web application, or an API? I think that this is the job of an access security authority. It could translate to coordination of OAuth, SAML, WS-Federation, OpenID Connect, CASB, EMM, or proprietary bridged mechanisms, all working together as a cohesive whole, because they are being informed and regulated by an authoritative entity.
With my Ping Identity colleagues I've written a new white paper that explores this new way of thinking about and describing identity architectures. The paper's goal is to assign modern roles to the high-level functions that govern most identity infrastructures. I'm very interested in what you, as Identity Architects, think about this new identity terminology, and how you might use it in your environments. Read the paper and let me know what you think on Twitter @pamelarosiedee. This is an important dialogue, and the more folks weigh in, the better!