Conflation or Confusion? You Decide

RWW Enterprise just covered the latest update of PingFederate in an article titled It’s PingFederate 6.6 Versus “Identity as a Service”. I couldn’t pass up the opportunity to comment on some details that made me cringe, so naturally this blog post was born. Please note that this is not about PingFederate in specific, a product I have no in-depth knowledge of. It’s about identity concepts and architecture.

To set the table, we need to make sure we understand adaptive authentication. The concept of being adaptive is at the heart of risk-based security models, which try to align the security protocols and mechanisms being enforced on the user and the organization with the risk inherent in the activity taking place. You can check out a talk I gave last year that expands on this a great deal.

Adaptive authentication relies on being able to measure certain details about the context (is the user inside the firewall or outside, the nature of the device being used, the kind of authentication already done and, obviously, the risk inherent in the transaction) to create a risk score that then determines whether the authentication level (and thereby the level of assurance) of the user needs to be adjusted. Products like Oracle Adaptive Access Manager and (presumably) PingFederate do this by providing ways in which applications can tap into them during transactional flows (in the simplest form, during login).

The title of the article seems to pit this security model against the concept of Identity as a Service (though nowhere in the article itself does this come up). But this is by definition IDaaS, because the application is externalizing the security controls it needs to a service provided by a 3rd party provider. When done the right way, the application doesn’t specify whether it needs the user to authenticate using hardware token based OTP, PhoneFactor or any other model. It simply specifies the risk factors in the transaction and lets the external service use configured policies to determine what is entailed. That way, a change in corporate security policy that switches from one authentication factor to another doesn’t impact the application. On top of that, PingFederate seems to be catering to security models that rely on social (federated) login, which is obviously an IDaaS model.

And even if you presume that Scott meant it as Identity Management as a Service, or more descriptively Identity Management Software as a Service, it still doesn’t hold because given the right integration points, the model shouldn’t impose any restrictions on where the service is run/hosted.

The article also seems to conflate (or confuse) authentication chaining with authentication against multiple identity stores. Authentication Chaining is a way to string together multiple, distinct authentication events (often in sequence) to create a stronger level of assurance about the identity. E.g. this user authenticated correctly using their username-password AND with a One-Time-Password sent via text message to their mobile number of record. Authentication against Multiple Identity Stores is about authenticating the user only once, but by checking it against different identity stores because you’re not sure which one the user is in.

The latter use case is where Virtual Directories are incredibly useful, because they can present a single, unified view to any consuming application, including an authentication application (like an SSO product). Virtual directories are also good at creating a single view of an identity whose attributes are split across multiple repositories (combining LDAP attributes with HR attributes, for instance). But this single view serves many different purposes in the IDaaS realm, especially for consuming applications and services that need that data at different points in time. It isn’t simply about creating a single token during authentication that combines these attributes. That’s why I don’t like the assertion (quoted in the article) that PingFederate’s attribute aggregation feature “makes virtual directory products unnecessary…“. There are many use cases where applications that have externalized identity need access to unified identity data outside of the context of an authentication event. Unless PingFederate actually includes a virtual directory service (which would make the above statement circular), I don’t see how they solve that particular IDaaS architectural need. And if you have multiple identity stores, you are going to have to address that need at some point.

So you see, in the end it is all about Identity as a Service.

[With that, I retreat into my bomb shelter to prepare for the onslaught from Paul, Pam, Patrick and Brian (who really should consider adding a silent P to the front of his name. Just for consistency)]