This video is number four of the Zero Trust Authentication Master Class series.  

Transcription

So, I'm still Jasson Casey, and apparently, you're still watching. So, now let's talk about how we move the conversation to the next level. And what I mean by that is we were just talking about the weaknesses of usernames as passwords and how they kind of create this residue across all of these different resource types that we now have to worry about in terms of data at rest security. 

There's an easy mitigation to reduce the scale of the problem but not eliminate the problem. And we might call that delegation or federation. And a lot of you already use this technique, but let's make sure you really understand how it works. So, to start with, we're going to go back to our primary trustee end-user, Alice. But now we're not talking about Alice and her banking needs. 

We're talking about Alice at work. So, Alice works at... we'll say it's the car company. Car company, because why not? And at the car company, Alice uses a couple of different applications. So, we'll say that Alice uses G Suite for email. 

And when I say Alice, I really mean the car company has decided that all of its employees are going to use G Suite, they're going to use Slack, and they're going to use, I don't know, Greenhouse for hiring. Not being terribly inventive. These are the applications we actually use here. But it makes things easier. 

So, it would kind of be a nightmare from an administration perspective if I kind of had to manage each of these applications independently. And it turns out I can actually use this thing called an identity provider, and we'll just say IDP for short, to kind of manage or administrate users across different apps. 

And not only that, but by using an IDP, I can actually delegate authentication or these applications can delegate their authentication of end-users to the IDP so that usernames and passwords don't have to be managed in each of these locations, right? So, by establishing a connection here, Alice can now essentially log in to the IDP and the IDP can vouch for Alice to the application letting Alice actually get access to that application without having to supply a username and password to that application. 

So, how does that actually work? There's two key technologies that we're going to talk about. They actually use very, very similar mechanisms. So, I'm sure you've heard of SAML. OIDC is kind of the new hotness. So, most application…if you're building a fresh application today and you wanted to go after the enterprise marketplace, you're going to start with OIDC because it's easier and it gives you a lot more flexibility, but then you're going to quickly be forced into supporting SAML as well to work with older legacy applications. 

But how do they actually work? How does federation or delegation work? Well, conceptually, it's pretty simple. I have what's called an end-user, right? So, again, this represents Alice. And Alice has a relationship with an IDP. 

In this example that we've talked about already, that relationship is, you know, an IT administrator provisioned Alice in the IDP, Alice then enrolled in the IDP using, again, a username and password. And that's really all that we claim. So, let's say this relationship exists. Right? 

Then let's call these things applications. There's other names for them. You may have heard of things called relying parties. You may have heard of things called clients. Depending on the system that we're actually in, the nomenclature can change. But again, there is a hard relationship between the IDP and the app, right? Because essentially what we're saying is when we create some of these federation protocols is we're saying because the IDP knows who the end-user is, the application is going to then trust the IDP to vouch for, in fact, someone is the end-user. 

So, by doing that, I can create essentially a soft relationship between Alice and the application. So, how is trust established between Alice and the IDP? It's established in this example with a username and a password. Maybe there's additional factors, right? 

Maybe not. It doesn't really matter. How is trust established between the app and the IDP? Well, it's typically established by the administrator, right, the IT administrator of an organization. And it can happen in a couple different ways. You can go in and essentially configure essentially a API key. 

It kind of looks like an API key in both of these locations, right? Essentially telling them that when you see this key, know that you should trust this app. You could also configure certificates, or put in another way, trust is established because I'm telling you to trust the holder or anyone who can prove that they hold the private key related to this particular certificate. 

And again, depending on the ecosystem we're operating in, we may establish trust in any of those ways. But once trust is established by those two parties, then essentially we can run a protocol. And I'll explain how it works here in a second. We'll just say protocol P, that will then essentially establish trust between Alice and the app for the purpose of a session. 

And this is going to be kind of fundamental for us to understand for some of our later conversations. So, at a very high level, Alice will attempt to access the application. So, we'll say one is access. 

And the application will basically send Alice and will do this with what's called a redirect to the IDP. And it's roughly saying, "Hey, I can't authenticate you. I need you to go to the thing that can authenticate you." So, Alice will come to the IDP and essentially say, "Let me in." 

And the IDP will go through a challenge-response and come back. So, I'm compressing things here. But we've already kind of talked through the authorized username and password. So, let's assume this is the happy path and Alice is able to successfully authenticate with the IDP. 

So the IDP is going to send back a redirect. It's going to say, "All right. Now, Alice, I want you to go back to the application and I want you to present to the application..." We're going to call it like a magic ticket. It's Willy Wonka time. "So, I'm going to want you to present this magic ticket back to the application and it's going to be able to figure out who you are from there." 

So, then Alice is going to go back to the application and Alice is going to present that magic ticket. Now, if we're SAML, that magic ticket is going to be enough for the application to verify the authenticity of the ticket, and it will verify that the ticket came from the IDP because it already knows how to trust the IDP and it's basically looking for a signature it can verify against a certificate that belongs to that IDP. 

And if that's the case, then it will just admit Alice. If it's OIDC, it's a little bit of a different flow. It will establish a connection back to the IDP and it will… We'll call this the redemption. It's going to try and redeem that magic ticket saying, "Someone's trying to access me. Here is their magic ticket. Can you tell me who they are?" 

And then the IDP will come back and it will have a… We'll call it a token, but you can think of it as an envelope with a bunch of things in it. And it will basically say the username is Alice and it will say a bunch of other stuff too. It'll tell you what Alice's rights are. And so this is more of the OIDC flow. So, what does this look like as a sequence diagram? 

We have Alice. We have the application. I'm just using application generically. Again, you might hear this called relying party, you might hear this being called the client. All three are kind of used interchangeably. And then finally, you have the IDP. 

You might also hear this called the off-server or service. Again, it can be used interchangeably. So, there's some initial access request. Then we issue what's called a 302. So, a 302 is how HGP says, "I can't handle your request, but I know that you need to proceed to this other destination." 

So, there's typically something called a location header with additional information. And essentially what you do is you then follow that location header. So, I'll then go to the IDP and I'll really just present what I learned here. Then the IDP will think about what to do. And what it typically does is it will then serve a Login page, right, with our traditional username and password box. 

Alice will then present her information, right, her username and password. And we'll say post-authorized with the envelope. The IDP will verify. And then at this point, the IDP will again redirect Alice. 302. But the location on this redirect will basically point to the app, but in addition to pointing to the app, it is going to have some additional named parameters, right? 

Remember we talked about a magic ticket earlier. So, Alice is going to go to the app. And I obviously can't write all this. So, she's going to copy it over. And the way the app redeems the magic ticket, and again now I'm following the OIDC flow, is it will issue what's called a post/token. 

Because it wants to get a token, it will convey a lot of this information that it just learned. Here's my magic ticket and a couple of other preconfigured things. There is a validation step and a lookup. And then on a successful response, it's a 200 okay with a token. 

Now, we keep saying token. What is a token? A token is…it's a JSON object which is really just...it's a fancy way of saying here is a bunch of name-value pairs. Turns out some of these name-value pairs can be nested. They can have lists, right? 

It's just a structure. But importantly, this entire structure, the checksum is taken of the structure, and then it's signed with a private key, which has the effect of sealing the payload. When we say sealing the payload, what we really mean is it's easy for anyone in receipt of this ticket to verify that the ticket hasn't been modified by anyone other than the holder of the private key who signed this because any such modification would render the signature invalid, right? 

So, typical things that show up in this token. Subject, like who are we talking about? Well, we're talking about Alice, right? What else would show in there is essentially what are the rights of Alice, right? When we talk about rights, we typically talk about scopes, right? 

Permissions. What does she have the ability to do in this work environment? Maybe she has the role of administrator, she's allowed to do everything. Maybe it's more narrowly scoped than that. I'm simplifying things here, obviously. Time window. How long is this permission good for? 

When does permission start? Ability to refresh, right? So, essentially a bunch of metadata that can be presented back to the application. So, the application can kind of know how should it present, what controls should it allow Alice to actually have access to? 

And this is the basis of delegation. And in almost every enterprise environment, you always have this model really doing two things, number one, it does reduce your surface area from an authentication protection perspective by having one thing to focus on instead of many. 

The second thing it does is it just… The other scenario where I have to manage this is an administrative nightmare. So, not only can we delegate authentication, but usually think like movers, joiners, levers, like when someone joins your company, leaves your company, goes on sabbatical, comes back, you want to disable them in all of the apps. 

You want to resume them in all of the apps. You don't want to have to log into all of them. So, typically your IDP will speak another protocol as well. Or maybe it has custom API integrations to these apps to really manage the life cycle. Whoops. Yeah, let's not write it there. The life cycle really of the identity. 

And remember, identities can be, you know, people or robots.