This will be the first blog of a three-part series examining how authentication (auth’n) — 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.
We’ll start, in this post, with a quick review of federated authentication: what it is, what standards apply, and how it differs from authorization (auth’z). The second and third posts, coming in a few weeks’ time, will look in more detail at some key new standards emerging for authentication (part II) and then (in part III) at how these can be used in the context of standards-based ABAC.
First, then, a quick review of auth’n and auth’z.
Most of you (I hope!) already know what authorization is: at the most basic level, authorization is deciding whether a particular subject is allowed to perform a given action on a specific resource. Historically, this was often done based on what group the user belonged to: hence, role-based access control (RBAC). Now, though, we’re interested in the more granular, and much more powerful, attribute-based access control.
So, what’s Authentication?
In it’s simplest form, Authentication answers the question ‘who is this subject’; so it’s a critical precursor to our auth’z decisions: if we can’t reliably and securely identify the subject, how can we hope to make appropriate decisions about what they can and can’t do?
That’s important for RBAC, but for ABAC it becomes even more crucial. Why? Because with modern authentication — and, in particular, with federated identity or SSO — we can find out a lot more about the user than just ‘who they are’. In many deployments, we can get lots of other information about them as well – geolocation, time of day, role, organisation, language preferences, whether they have a paid account for our service, whether they are carrying out an action on their own behalf or for someone else…. maybe even information about how they authenticated in the first place (username/password? security token? something else?).
All these other pieces of information are called ‘Claims’ (typically in the Microsoft universe) or ‘Attributes’ (by pretty much everyone else). And yes, we can absolutely use them to help inform our Attribute-based Access Control decisions!
Here’s an analogy. Let’s say Alice decides to emigrate from the UK (where she lives and is resident) to the US. So when she arrives in San Francisco airport, she presents her passport, which was issued by the UK. This is an authentication process. The border control agent checks her passport, and, assuming it looks valid and OK, they will let her into the country.
In this example the UK is the Identity Provider (also known as the Asserting Party) and the US is the Service Provider (also known as the Relying Party). And yes, you could argue that in this example, I’ve actually done two things: Alice has authenticated, but she’s also been authorized to do her first action: enter the country. Analogies are rarely perfect!
As an interesting side-note: Alice’s passport has been issued by the UK Government, and (thanks to a bunch of treaties that both parties have signed over the years) the U.S. Government trusts the UK Government to have identified her properly (they don’t trust other Governments quite so much — which is one of the reasons why Alice might have to get a visa as well. The visa provides evidence of additional checks of her identity: multiple factors of authentication at the identity provider. Put another way, the visa provides an additional Level of Assurance that Alice is indeed who she claims to be.)
Now, let’s imagine that Alice wants to access some other U.S. Government Service. For example, she might want to apply for a driver’s license. In order for the U.S. Department of Transport to authorize her to get a license, they need some other things. They need to know who she is — her passport will suffice for that — and they need to know that she is legally allowed to be in the country. That’s established by the simple fact that the border protection officers let her in: the U.S. DoT trusts the U.S. Customs and Border Protection to make that decision. But they need some other information — some other attributes — as well. They need to know if she can drive at all, if she’s old enough, if her eyesight is good enough, and so on. At this point, we’re into our attribute-based authorization process.
So now let’s map this back to something a bit less physical. Having just won the lottery, I go online to buy some Champagne to celebrate, which I choose to do at the (fictitious!) bubbleFizz.com online store. First I have to authenticate with bubbleFizz.com so they know who am I; and because they are a nice, modern company, instead of taking me through a lengthy and dull process to fill in my personal details, they let me log in — authenticate — using a social identity provider… Flitter (also fictitious), for instance. So now bubbleFizz trusts Flitter to assert that I am me; and this trust is established in reality by a cryptographic exchange, probably supported by a commercial agreement of some kind to keep the lawyers happy.
Great! I authenticated with bubbleFizz, but now I need to buy my Champagne. To establish whether or not I can be allowed to do that, bubbleFizz needs also to know my age, and to find out, they are going to use a third-party attribute service. They will send my identity across (hopefully in the form of a nice encrypted token — but we’ll get to that in part II, I promise!) along with a query asking if I’m over 18 (which is the legal minimum age where bubbleFizz operates). They will get a yes/no response. And they can then go ahead and authorize me to start choosing my Champagne (the Dom Pérignon ‘65 is looking good….!)
What’s particularly special about this example is that role-based access control really wouldn’t help us a lot. Yeah, you could kludge something together (probably by adding me into your customer database in the role of ‘overagePurchaser’ or something) — but apart from being an ugly solution, it also forces you to store me in your database; and doesn’t allow for the extended example where I want the bubbleFizz iPhone app later on to make a purchase on my behalf…. 🙂
No, this is clear case where externalised ABAC will help us run a centralised policy which all my applications can call (bubbleBeer, bubbleCider and so on); and which will mean I can be compliant with age restriction requirements even when they change. And I get my attributes by implementing proper, modern, externalised authentication as part of my solution.
So: hopefully that helps clear up what auth’n and auth’z are. In part II, we’ll examine the auth’n standards at play in the example above (and in particular, SAML, OAuth and OpenID Connect).
Authentication vs. Authorization – Part 1