This is the second post of a three-part series examining how authentication – in particular, federated identity and standards-based single sign-on (SSO) – and attribute based access control (ABAC) interrelate, and can interoperate in support of some interesting use cases. Read Part 1 for a quick refresh.
This post builds on Part 1 to explore in more detail the key standards for authentication, both existing and emerging and lays the groundwork for a closer examination in Part 3 of how these can be used together with standards-based ABAC.
Let’s first make sure we’re clear about exactly what we mean by ‘authentication’. I’m not going to cover multi-factor authentication and related work being done by groups such as the Initiative for Open Authentication (OATH) or the FIDO Alliance. This is an interesting topic all to itself, but too much to cover in detail here. Nor am I going to cover internal-only authentication standards and solutions like Kerberos or Novell NetWare. Integration methods with solutions like these are fairly well understood; and more importantly, these solutions are being superseded or extended by cross-domain authentication — otherwise known as ‘federated identity’. This is the area we’ll cover here.
It’s beyond the scope of this post to get into detail about why identity federation has grown so massively as a key component of enterprise security architecture over the past few years. The bottom line is that as business software has become increasingly distributed – either because it shifted from internally hosted to cloud-based (public or private); or because increased numbers of users needed to access applications from outside the organizational boundary – so the old architecture of putting everything behind a big wall and severely restricting inbound and outbound traffic has fallen apart, a process known as ‘de-perimeterization’.
In its place, a new architecture has emerged whereby the user identity stays safely in the ownership of the relevant organization; and identity information is exchanged through the use of secure tokens. This provides improved security, reduced risk, and supports modern business practice much more completely, both for business-to-business and business-to-consumer models.
Without rolling the clock back too far, the key standard in this space for the past few years has been the Security Assertion Markup Language (“SAML”). SAML has evolved into a mature, powerful standard, and there are lots of different deployment models to support some fairly complex use-cases.
At its most basic level, SAML presumes two primary roles in any transaction – the organization where the identity is established, known as the Identity Provider (“IdP”), or Asserting Party (“AP”); and the organization which (for this transaction) wants to use this identity, known as the Service Provider (“SP”), or Relying Party (“RP”).
It’s important to note that a given organization might act as an IdP for one use-case (for instance, its employees need to access external, public-cloud-hosted applications like Salesforce or Google); and an SP for another use-case (the company provides access to a supplier portal, and doesn’t want the risk and overhead of managing those external identities).
Again, there are lots of ways the SAML flow can work, and be adapted for specific requirements; but the most common flow looks something like this. A user attempts to access an application with the Service Provider. The SP needs to establish the identity of this user, and so sends an auth’n request to the Identity Provider. SAML 2.0, the most current version of the specification, also provides options to discover which the right IdP is. We’ll assume the user is already authenticated with the IdP (if not, the IdP can take care of that however it needs to – this is often the place where a multi-factor solution might be used) and so the IdP can send back an ‘Assertion’ to the SP. Now the SP knows who the user is, and can process that user accordingly:
It’s common for the IdP and SP to be separate organizations, but it’s certainly not required, and there are plenty of examples of companies using this approach to integrate across internal organizational boundaries.
The ‘assertion’ is a statement of identity that the IdP makes to the SP; and which the SP can trust (this trust being established from a technical standpoint by a cryptographic key exchange). The SP and the IdP will normally agree upfront what information the SP is going to need — although there is a mechanism to go back after the initial transaction and request additional information (specifically, the Attribute Query Profile (PDF) of SAML 2.0). This agreement is known in the specification as the ‘attribute contract’. At the very least, the attribute contract must contain a ‘subject’ which typically identifies the user who is making the request; but it can also contain whatever other attributes (or claims) the SP needs to make your application work.
And one of the primary things the SP needs to make the application work properly is the ability to make access control decisions. So the nice thing about the federated identity flow is that it provides you much of (in some cases all of) the context the SP requires to then feed in attributes to an ABAC decision-making process. Example?
OK: let’s imagine the SP has a policy like “Suppliers can access product design documents if they are from a certified supplier and they have authenticated with multi-factor authentication”. Alice is an engineer with the supplier, who needs to access a design document. The flow looks something like this:
Note the flow of information between the SAML Service Provider, the PEP and the PDP. There is more one could do: for instance, it might be possible to go back and request additional authentication if the original SAML Assertion did not contain the right Level of Assurance (most likely the way that information about whether or not a strong form of authentication had been used). But the basic structure should be clear.
Now, this works just fine if the user is a human being. But what if it’s an application making a call (on behalf of someone or something else) to an API – say, a native app on a mobile device? Well, some other standards apply in that case. For SOAP-based calls (less common), WS-Trust is well established and frequently used. For RESTful APIs (by far the more prevalent), OAuth 2.0 and OpenID Connect (which is a profile of OAuth) are now properly standardized and rapidly becoming adopted as the right way to handle identity in this context.
Although the basic principles are the same, the flows are necessarily different; in the main to account for capabilities of the device (or other calling application) and the user experience on the device. Perhaps most importantly, it’s worth pointing out that OAuth introduces the notion of an ‘authorization token’ and a ‘refresh token’. It’s important to understand that the ‘authorization’ token simply says that the client application has the right to access services on the server. However, it does not supersede any access control decisions that the server-side application might make. Here’s a common (but not the only possible) flow:
It’s important to stress in both of these that OAuth is solely responsible for saying that the device is authorized to make the request (on behalf of the user). The service still needs to decide whether the specific request that has been made is actually allowed. The OAuth Authorisation Service does not know of that – indeed, quite frequently the AS will be in a different organization, so how could it know! That’s where the PDP comes in; and just as with the SAML example above, it’s perfectly possible for identity attributes from the token to be shared with the PDP as input to the decision.
So where does XACML fit into all of this?
To properly evaluate a given policy statement, XACML needs contextual information about the subject and (potentially) the resource they are accessing. With a standardized inbound identity protocol such as SAML or OAuth (and OpenID Connect) it is much simpler for the XACML deployment to leverage identity information in a standard way – allowing the architect to extend the benefits of a modern identity stack right the way down to the fine-grained access-control level.
That interoperability exists at a product level for several implementations – as an example, it’s possible to use a federation product like PingFederate, or an access gateway like PingAccess, as a PEP for an Axiomatics Policy Server deployment. Interoperability also exists at a standards level: there is a SAML 2.0 profile for XAML (PDF) and there is an XACML attribute profile for SAML 2.0 (PDF – starting on pg.62).
In Part 3 we’ll work through a specific example, bringing all of this together.