as we continue working through identity, entitlement and access management,
and we'll start off by reviewing some of the general considerations for identity access. Management in the cloud will go over the basics of Federated Identity.
Then we'll dive into popular I am technology standards and finish off with an open I. D. Authentication example.
As we move into a cloud world, it's possible to have hundreds, potentially even thousands, for a large enterprise of different SAS providers and this fact, along with other cloud characteristics, really have an impact on identity and access management. There's a lot more rapid rate of change, especially the SAS providers, because you're not
directly controlling those. That's part of the service that's being given to you
and outsourced is that those updates and upgrades and changes air happening? You have distributed applications so you don't necessarily know where all the SAS providers are. There's gonna be many that you do have a tight governance around for data jurisdiction and so forth, but it's going to be beyond your own internal network.
In fact, the communication goes over the broad network, the general Internet,
so that creates a situation where you have a shared responsibility between the cloud provider and the customer. When it comes to identity and access management provider needs to expose a variety of controls to you and then the customer. You need to configure those controls appropriately. Now, taking that background and moving it forward.
What are some of the basics of Federated Identity? And how does it sit into the picture?
Bear in mind what we talked about hundreds of different SAS providers and so that can add some very complicated operations. If you have hundreds of different systems and hundreds of different user names and hundreds of different passwords that you need to manage a zone I T administrative team, or even as an end user,
you're gonna have all these different identities and it becomes very difficult to keep track of them.
I'm sure in your own experience you have Loggins, too many different websites and many different passwords, and hopefully you aren't using the same passwords for all those different websites and the same user names for all those different websites. So you do have some sort of silos in case one gets compromised at the same time, it creates a lot of confusion for you
And when you look at doing this at an enterprise scale, the same rings true. So by centralizing the account and access management capabilities,
it really simplifies operations both for the administrative teams as well as for the end user teams. And finally, federation brings an opportunity to use the latest and greatest I am technologies and really refining your own internal processes. Some will be talking further about that in this module, but just understand it. It is a new paradigm
that has a lot of benefits.
Four organizations is whole as well as individual users, and any time you entering the new paradigm, it's an opportunity to revisit the way you've been doing things historically. And maybe adjust altar and optimize those things. Let's talk to three of the most popular identity access management technology standards in the cloud. At this point,
we have the security assertion markup language, also referred to as Samel,
so that this paradigm supports both authentication and authorization capabilities, and you have a communication line between the identity provider and the relying party, and it's all done back and forth using an XML formatted communication. And Sam has been around for a while, so it has wide support.
But the initial configuration of it to get your organization starting
does have a learning curve moving on. We have Oh, off. So off is just an authorization based protocol. So it doesn't deal with the authentication. Unlike Samel, which relies on XML, this operates over http, using the rest and Jason Paradigm. And that may not mean a ton to you,
but it is just a a newer approach of technology. So what that tells you this
hasn't been around quite a long a sample. It also has some actual benefits in terms of making the management and the development and ability to support this protocol a little easier for the parties involved. However, there's a 2.0 version of O off
and a 1.0 version of O off. And those two aren't quite compatible. So you're gonna have some problems there when you're talking to a vendor and they talk about a lot of support is gonna be worth
clarifying. Are we talking two point? Oh, are we talking about one point? Oh,
and finally open I d. So this is the authentication. This is I ensuring the identity the person is the identity they are asserting they are. This also operates over 80 to be an arrest. So it again it's it's newer than Samel, and it is based primarily on the connect 1.0, standard.
So in this hypothetical scenario, we're gonna walk through the open I D authentication. We have a user here. He's telling a relying party. So this is some sass service. Let's say he says, Hey, I am joe dot cool. That's my user name.
Then the SAS service in the back end is a relationship with the identity provider is a trusted relationship, and it's going to say this individuals trying to contact me I don't really recognize who they are. Are they who they are, who they say they are.
Identity provider is gonna talk back to the relying party and say, I'm not so sure either.
Send them my way. I will make sure that they are who they say they are, and then I'll let you know in a moment. So then the relying party sends back a message to the browser, and it's gonna redirect. Joe Cool is gonna have to go to a different interface
and enter his user name and password. So he does. That is, Well, here's my user name. And here's my password.
The identity provider receives that information, and this example. I've decoupled the identity provider with the authoritative source. Let's say that the authoritative source maybe is an on premise Windows Active directory or something of that nature to the identity provider. Takes those user name password credentials. It's gonna
communicated with the authoritative source and says, Does this match up is this
makes sense. Is is truly Joe cool? Should I assume that this individual or this entity rather should be assigned this identity through the process of authentication?
And we'll say that the user name and password was correct, because this individual is not perpetrating somebody or masquerading to be somebody that they are. And the identity provider says, Okay, great, you have been authenticated. Here's a special token for you to use
as you continue to communicate with additional relying third parties,
and then he's gonna take that token, and he's gonna hand it off to the third party is gonna be the browser. Your actual Web page will be redirected going back to the relying party, and it's gonna send the token there. And the relying party has a trusted relationship with the identity provider.
So the two of them have agreed that this is a token, and this is a format that can be trusted,
and so he's gonna provide that. And that's just a real simple way of looking at how the authentication process happens in a Federated environment. So at no point does the relying party actually have the password him because it's been centralized. Let's say Joe Cools, account
gets decommissioned, and the authoritative source will say either the wrong user name and password will say, You know what? That account is no longer valid.
The relying party is not going to get this token so that you don't need to have the synchronization of information across so so many different third party SAS providers, past providers and so forth. You've centralized the access management and the authentication in this situation. In this video, we reviewed identity and access management in the Cloud
Federated Identity Basics
popular. I am technology standards, and we did a nice walk through through the open I d authentication example