OpenID SSE, CAEP and RISC - Critical standards that enable Zero-Trust security

All right. Hi everyone. My name is Tim Capelli. I'm a standards architect at Microsoft, and I actually quick intro about a tool and I, when we met, so I was actually at a previous company, a network identity and security company, and a tool had approached. I don't even remember how we got initial contact, but a tool approached me about this Cape thing, the vision that a tool had, and immediately we thought, you know, traditionally network identity and network context is not part of the picture.

And, you know, very few identity folks work in the network identity space. So a tool was already in the cloud identity space, and we had a few other folks from all different kind of lenses on the problem. And we kind of came together. I think we had an initial meeting at Google and mountain view, moved it to, I w if you're familiar with internet identity workshop, and then more and more people came on board and we ended up in the open ID foundation with a big working group. And so that's how a tool and I ended up working together on, on this use case. Great. All right.

So let me start with sort of the background here, right? So one of the key things in zero trust is that, you know, you are, you are supposed to check every access, right?

You're, there's no firewall or something to prevent access if something goes wrong, right? So you have to verify every access independently.

Now, the problem is that using federated identity standards like open ID connect or SAML, you are getting a snapshot and time kind of authentication, right? So let's say in a mobile app that I'm using has authenticated me, you know, two days ago, right. And I'm still using that authentication with Salesforce or something else. Right. And since the authentication gets stale, there's no way today.

You know, there was no way in, in the past to, to dynamically adjust that, that authentication based on the changes to your environment, right? To, to your phone or your, to, to the application, or, you know, to your status as an employee, which gives you the rights to have that app access. Right? And so that's sort of the background here. And like I said, you know, context is always changing. You might be at a public location, a private location in one instance. And then a few minutes later, you may be in a public location.

Your session is gonna get stale because you're not like, you know, you're in access, properties are gonna be changing all the time, right? The device may be compromised. The application you may be using may be outdated.

You know, various things can happen like your, your change, your reset, your password, or your, your, your employment status has changed and things like that. Right? So all those context, but, you know, events are siloed. And without a standard that can propagate these events, independent providers, like your SAS applications cannot actually communicate with your, your identity provider to, to share these events.

And so that's how we came up with the idea of sort of, it was called the continuous access evaluation protocol earlier when, when the first block post came out, you know, three plus years ago now. But what it basically did was it, it postulate a way in which, you know, independent parties can sort of asynchronously send event updates to propagate the changes. So sort of to, to break the silos. Right. But at the same time, it did not actually prescribe any particular action on the B on the part of the receiver. Right?

So it was just an event notification that said, Hey, you know, I've, I've seen this change. Like this user's password has changed, or, you know, this uses IP address has changed or something like that. Those changes have been communicated, but it doesn't require the recipient to actually do anything with it. And that's sort of the good thing about it because it's more sort of descriptive rather than prescriptive, right? A lot of debate in the early, early days of the standards development.

And it's like Tim said, it started as an independent effort, but you got merged with the risk working group in open ID. And now we have the SSE working group. Right. All right. Where this, the reason this ended up in the open ID foundation, one was we needed a home. Let's be honest. The second part is we thought it actually fit really well into the overall story at open ID. If you came to the open ID workshop, sorry, this may be repetitive, but there's really four big components that we see and really spec families that we think combined to create kind of this circle of Federation.

And so the first one is fast Federation, which we won't talk about here, but ultimately it's, it's a way for an easy button to set up Federation between new parties. That's something that many folks mess up. They copy and paste the wrong file. They upload the wrong file. The file's bad, all these things that just, it it's super complicated for no reason. I see a lot of heads nodding. So we wanna actually fix that with fasted easy button type setup, you know, replace login with Google, with set fast Feder set Federation. That's the model we want. So that's one component.

Then we move over to skim, which is all about user group and device object, permissioning provisioning, right? So typically typically services use just in time provisioning. That's not helpful for things like file sharing, where you need to have users populated in a, in a search box, right? You need to know about the users you wanna share with before they necessarily sign in. So that actually actually been, this is not in the open ID found foundation actually, but all of these other things touch on it. It's actually being rechartered in, I ETF to support some new use cases.

The next one is obviously open ID connect for sign in, and Sam is over here too. But you know, that's, that's in a different group in a different, in a different cycle of life. And the last one we believe is SSE, which will allow us to bring kind of all of this full circle, right? Set up Federation provision users, let the user sign in control the session. So we think this comes together very nicely. And I think in an ideal world, we're gonna have one SDK that does all of this, right. That developer can just deploy right. Pipe dream, but hope we'll get there.

And in terms of the family, I don't wanna get too deep in the weeds. But the nice thing is we, we borrowed a lot of existing specs. We tried not to reinvent the wheel to the right hand side as all the fun IATF stuff that runs under the covers. Things like a security event, token, which is like the, the signed object that you actually pass to carry the event. And the nice thing is from a transport perspective, we support pull based and push based, right?

We, we expect many folks to deploy push, right? You want just get notified, but there is an option to have like a long pull style method as well.

For, for the there's certain scenarios out there. There's still folks that can't open a firewall for inbound messages, for example. So being able to pull is also an awesome option. And then we have really what we're talking about here, which is the actual, if you up level that these are the profiles of all these other specs that give us the solutions, that's typically open ID tends to profile existing artifacts from other groups to come up with a holistic solution. And that's what we're talking about here.

So a world without SSE right now, which is really where we are now, there's, we're slowly getting some deployments, but you know, you have this world where, you know, here's how you set up AWS, Microsoft sale point Okta. These are all different ways to set up more or less web hooks, right? What we think SSE can bring to the world is a, a standardized framework for web hook web hooks, right? WebBook are quote easy, right?

You post adjacent object to an endpoint, you get a 200, but that's, it doesn't handle how you subscribe to events, how you, you know, it doesn't handle all the stuff on top that is required. Cuz most, most web books are unauthenticated posts, right? Which have their own set of challenges. So we wanna make sure that we get to a point where you don't need these company specific directions. You have one, you know, one framework, one SDK, maybe the only thing you have to learn about is how to authenticate to that API.

Something that is typically going to be platform specific, what scopes you need, et cetera. So we, we hopefully, hopefully this will all go away and we'll have one single doc. So this is kind of what it would look like.

Platform, a platform, B any platform can be a transmitter or a receiver or both. We imagine actually once this rolls out, especially between larger SaaS providers, you're gonna be both a transmitter and receiver, cuz you're gonna wanna provide context and receive context and they're completely independent for each other, but you can correlate them however you need them. And so from a, from a management standpoint, what SSE provides as, as kind of the upper level management framework is stream configuration status.

Being able to express interest in a subject, one of SSEs most valuable features is something we call complex subjects. So traditionally before this kind of revamp of the work, there was very, very basic way to express the subject. Right?

I want a, I wanna subscribe to events about a user with the email address. And that was really it. Now we have this idea of complex subjects where if you think of a lot of a tools previous presentation, you know, it's not just about the user, it's the user on a device with a session. So now we have a way to actually convey all three properties with a structured format of, you know, it could be, you know, the, the username is an email format, which is not ideal, but real in reality, that's how people stored in the database.

The device may be a good and the session may be an arbitrary opaque value, but being able to express that I want to only affect the session that's for that user on that device is hugely valuable for some of these zero trust scenarios. So if we switch platform B with platform C it's the same set of things, right? That's the goal, this is all abstracted away. The most important part of all, this is actually the discovery process. Yeah. All right.

So let's, let's go through a concrete example here. Right?

So, so this is sort of the example that we are working with, like right from the beginning, right? So this is a user who's using an identity provider, like let's say Microsoft Azure ad to access a file sharing service, which could be something like Dropbox or something like that.

And so, you know what the user is in a secure location, they're either at work or at their home, and they're using the IDP to sign into the file sharing service. And because the, the user is in a secure location, the token that grants them access has the property that, you know, that that user can have PII access, you know, personally identifiable information access, right. And once the user is signed and the IDP and DSP sort of share subscription about that user.

So basically the IDP tells the SP that, Hey, I want to know if anything changes about the user's context, same thing with the, the SP the final sharing service will tell the IDP, if something changes about the user status, I would like to know about it, right? So they both subscribe to each other's events. And so when the user tries to access the document that uses PII, because the user's location is secure, that access is granted. Now the user picks up their laptop, and then they go to a cafe, which is a public location, right? So now the user's access properties have changed.

Now when the user tries to access the file service, what the file sharing service, what Dropbox will notice is that the user's IP address has changed. Now, what it'll do is it'll just generate a Cape event and send it to the IDP saying, Hey, you subscribe to this user's changes. Here's the change that I've observed that uses location has changed.

And so now what happens is that the identity provider recomposes policies based on that change, and it may do nothing, but it may, in all likelihood, it can, it'll send back an event asynchronously saying, Hey, now that this users location has changed, these are the new claims for that token that I've issued you. Right? And so now the file service knows that this is a public location and the user should not be granted access to the PII. Right.

And so, as a result, when the user tries to access a file that contains PII, you know, that access is, is refused. Yeah.

And, and, and as we, as we show this example, we're probably gonna need to start adding some more to this use case, cuz I think this is the quintessential use case, but it does highlight. I think the contextual change IP address obviously is not always the best, but it is, it is fair. It is a fairly good use case, right? A user shouldn't necessarily be doing HR stuff on open wifi in, in a, in a coffee shop. And it's not even the open wifi anymore. Like everything's encrypted, it's the fact that shoulder surfing and there's people around.

And there's just other, other things that make that a problem. And so as a tool mentioned, right, in this case, when the IDP sent, sent an event to the file sharing service, it could be as generic as revoked the session, but all the way down to something like a token claims change, right? So you could actually say, you know, users are constantly moving, you know, let, let's keep with the IP example, just cuz it's easy to explain users. IP constantly changes over the course of the day. Do you really want to min a new access token every time they do that?

Or could you just tell the service provider or the IDP like, Hey, the IP change. So could you just send an event that says if the, if the original token claim is IP colon, the IP address send an event that just says token claims change new IP, and then you need to keep minting access tokens constantly. So that that's that's one example of the token claims use case credential change is another one, right? A user adds a phyto authenticator to their account and they were using a weak authenticator before.

Maybe you want to be notified so that you can give the user higher privilege or maybe you send them back to the IDP to now use that pH authenticator device compliance change is probably the one everyone knows, right? My device was compliant in the MDM. Now it's not, that's very important information to many parties. And then the, you know, as you may be able to see here, the difference really between Cape events and risk events, you can think of the Cape specification and the risk specification more or less as dictionaries, right?

They probably could be simpler in like a registry, but you know, a spec is, is the easiest way to convey what the properties of these events mean, but they're really more or less dictionaries for certain use cases. So Cape we kind of position as the zero trust use cases, risk is kind of been out actually in the wild for quite some time, which is really around account life cycle, right? So for actually very much targeted towards consumer accounts, but there's nothing stopping you from using these events for enterprise accounts as well.

So the common one account disabled identifier changed, right? So on an account, the user changes their email. That email address was used as the primary identifier there's parties that may wanna know about that because they may be using it in their system in terms of industry adoption. So Google actually has been doing this for, I don't even know when it started, but very long time, this cross account protection model, that's actually what the service is called in Google cross account protection service.

If you actually go into your Google account, you can actually see where it's actually declared in your account. And the idea is that, you know, you can send risk events to applications leveraging signing with Google, right?

So if I, if I wanna log into Xbox with my Google account, it's probably in, in the Xbox team's best interest to know that you maybe no longer have access to the email address that you provide, right? Because then if that's compromised, you could reset access to all of these different accounts. So it's a really flexible way to allow parties to, to share this information with as little information as possible, right? A lot of the claims in these events are optional or the claim, the event strictly prohibit or strictly restricts what you can actually send, right? It's least privileged by design.

There's hundreds of thousand of applications in production. Anyone that's using the Google SDK I believe is automatically using it, which is amazing. That's the model we want to get to as part of building this into that circle. And there's millions of events sent per day. I'm looking at a tool cuz he worked at Google as, I dunno if you mentioned that, but I have an authorization to, to share this information.

So, and then I can speak on behalf of Microsoft, we are actually leveraging this. We started leveraging this early on in COVID right? One of the things we ran into was obviously usage went through the roof. That means the number of tokens issued, went through the roof and you know, our access tokens used to be one hour, right?

That was, that was what we minted for security reasons. And we said, Hey, what if the other party that's leveraging this access token could be Cape aware and we know that they can receive the event and process it. Maybe we can increase the token to 24 hours because now we have a mechanism of telling the other party, the, to the session was revoked, right?

So it, it also helps with large scale architecture in terms of being able to, to issue longer tokens, but still having the assurance that that session can be killed. The pull switch can, you know, the, the eject button can be pushed. So we actually use this currently, if you've heard the continuous access evaluation, it's unfortunately very close to the profile name. I lost that battle. So that continuous access evaluation feature in Azure ad one of the components is leveraging Cape event, which is session revoked.

And so anytime you interact with something like exchange or SharePoint or teams, they're actually potentially getting a revocation event from Azure ad. And that's why you either have to do a, do a second factor re-enroll or you just get signed out. That's actually what's driving that the next step for us, right? We want to prove this out internally, make sure it worked at kind of Microsoft scale. And our next step is now to be able to expose those events to third parties who want to leverage the data and even potentially support some of those additional event types. Yep.

And like you can see these are some of the busiest services from Microsoft, right. And that that's we want, like, we just wanna make sure it was solid before we start. We didn't wanna make third party developers do all of this change if it didn't prove out. Right. So it was a nice, it was a very large dog food test run in terms of some other efforts, special shout out to the Cisco team, they actually went, they didn't even tell us they just went and did it. And it was amazing.

They created a site, created a video, which will show in a second, all dedicated to really the developer focus on all this really easy to use. No one likes tore specs. They created essentially a light version of the spec and a, you know, illustrated way with code snippets, which is amazing. They just did that on their own and published it. And it was really awesome.

Sale point has released an open source data model on their, on their GitHub, which actually is really helpful in just, you know, you can pull that into any language and be able to process events and understand that the event, the event format and, and data model, and then Vera clouds has actually just released a production service that utilizes SSE in risk for event sharing. So they're, they're a password compromise company.

So that's, that's one of the first companies as one of the first companies besides Google and Microsoft that has done this. And they've actually been heavily involved in the working group. And so real quick we're in terms of the working group, please get involved. If you're interested, we want to explore some new use cases. I'm gonna skip this. We'll wrap up with the video since it's One of the first things we learn in life is that sharing is good. It's the right thing to do for everyone's benefit.

It's a lesson we're learning in cybersecurity too, because when your security tools share data with each other, your whole ecosystem becomes much more efficient and effective. But the challenge is with thousands of security solutions now available that information usually sits siloed in the various tools dashboards. What the industry really needs is a universal language that lets all security tools talk to each other in an easier and more simple way. Introducing the shared signals and events framework, an open API that allows communication between security products from any vendor.

The framework is based on five primary communication concepts. Whenever a subject experiences an event, the transmitter sends information about the event to a receiver via a stream. Each product still performs its core function, but now its data can be efficiently shared with other systems to give context, allow automation and better enforce a zero trust environment. Shared signals is being adopted by some of the biggest names in technology. And you can download sample code to try yourself because insecurity like in life sharing, it was good. Explore more@sharedsignals.guide.

That was a little marketing, but the goal, it really highlights the vision of what we're looking for. And it's a great way to, it's a great visual way to, to get folks interested in it. So I think that was it for us. If you want more information, open id.net/ssc brand new site that was just updated by a tool. So I don't think we have time for questions, but great. Well first tool. Thank you very much. It was really thank you very much.