- In this lesson 19.2,
we're gonna take a look at federated identity.
Before we start talking about federated,
let's just define SSO.
SSO or single sign-on,
we've used for quite a long time in our environments,
and often we refer to the older version,
of SSO as a legacy single sign-on.
Now, the idea of single sign-on was that users
could access multiple applications,
within the same organization,
or domain using a single set of credentials.
You would have a single sign-on server,
who would act as a proxy,
and you would only need to have one set of credentials,
and the proxy server would on your behalf,
actually authenticate you to different applications.
So that worked, I don't know, maybe about 80% of the time,
but what a great idea,
not to have to have different sets of credentials,
when you're logging into different applications.
Well, federated identity goes a step further.
Federated identity enables users,
to access applications or platforms,
across multiple enterprise domains,
that are part of a federated configuration,
using a single set of credentials,
and that's referred to as a portable identity.
So just to be clear for the difference,
legacy single sign-on where the users
would access multiple applications within
the same organization or domain,
using a single set of credentials,
with federated identity,
it enables users to access applications,
across multiple enterprise domains,
that are part of a federated configuration,
using a single set of credentials.
So they're independent organizations, right?
Independent.
Now, a federated configuration is just a configuration,
in which resources belong,
to different organizational entities,
so they're not related to each other.
Federated identity management refers to the processes
and technologies involved in managing user identities,
access rights, and permissions, across federated systems.
Now, federated identity management, or FIM,
includes identity provisioning authentication,
which is proving your identity to be genuine,
authorization which is the assignment,
of rights and permissions and attribute sharing,
between participating systems.
Now, the technologies used to implement FIM,
includes security assertion markup language,
known as SAML and OAuth 2.0.
So we're gonna dive deep into both of those.
I wanted you to understand how SAML works,
and how OAuth 2.0 works.
Now, SAML is an XML based open standard,
for exchanging authentication.
That's proving your identity be genuine, and authorization,
which is assignment of rights and permissions,
data between a service provider and an identity provider.
So we start with a user.
We have our user that's a subject,
who needs access to multiple systems or services,
remember, independent ones with a single set of credentials.
Then we're going to have an identity provider.
Now the identity provider is going to be the system
responsible for authenticating the user's identity,
and then identity provider will serve multiple enterprises.
And then we have our service provider, or our SP,
that's the system or the application that the user wants
to access and it's gonna rely on the identity provider's
assertion to trust the user's identity,
and grant access to its resources.
So let me give you an illustration,
and then we'll walk through it step by step.
So in SAML, we have three components.
We have the end user,
the end user is referred to as a principle.
We have the identity provider or the IDP,
that's our SAML compliant authentication service.
And then we're gonna have a service provider,
and that's a SAML compliant web application.
Now, we'll have lots of service providers that interact,
with that single identity provider.
So here I am, the end user, I want to log into
the service provider, I access the service provider.
I go to log into the service provider.
The service provider says, "well, okay,
but I'm really not the one that's gonna log you in."
And you know, either with my knowledge,
or sometimes transparently will send the request,
over to the identity provider,
who will then authenticate me, right?
Ask me for my credentials.
If I am appropriately authenticated,
we'll create an access token.
That access token will come back to the service provider.
The service provider will layer on my authorization.
And at that point, I will be allowed in.
SAML in this configuration is commonly used,
by businesses that offer subscription,
or pay services like Salesforce or Box.
So let's kind of walk through a little bit of a deeper dive.
The user initiates a login process,
with the service provider.
The service provider redirects the user,
to the identity provider.
The identity provider prompts the users for credentials.
The identity provider verifies the user credentials.
And if accepted,
the identity provider generates that security token.
That's the assertion.
The user is redirected back to the service provider,
with the security token,
the service provider validates a security token,
with the identity provider to ensure authenticity.
And then if the token is valid,
the service provider grants access to the resource.
Next, let's look at OAuth 2.0.
Now we're gonna look at OAuth 2.0 a little bit differently.
We're gonna look at it,
from an authorization standpoint, where SAML,
we looked at it from an authentication standpoint.
Now, OAuth 2.0 is an open standard protocol,
and framework designed to provide secure delegated access,
to resources without sharing credentials.
What an interesting concept,
so we're going to have three components.
First, we're going to have an authorization server, API,
an application programming interface,
and the resource itself.
That's the server that authenticated the user,
and issues an access token to the resource server.
We'll have a client application,
and that's the application or website,
that wants access to a protected resource.
And then we'll have a resource owner,
which is the user who owns the protected resource.
Let's take a look at OAuth 2.0 illustrated.
We're going to have three components.
Our resource owner, our requesting client application,
and then the resource,
which also has an authorization server, API,
or application programming interface.
So let me give you a little story about this.
I'm gonna be the resource owner in my story here,
and I'm gonna tell you,
that I really love playing online poker.
Now, I never play for money.
I only play for for chips, but I love playing.
And so the requesting client application,
let's say, is the poker game I play.
And one day that requesting client application says to me,
"hey Sarah, wouldn't you really like
to play poker with your friends?
Wouldn't it be more fun if they were at the table?
Or, wouldn't you like to know which one of your friends
has accounts and you can invite them to your table?"
I think, yeah, that would be cool.
I could stop playing with strangers.
That would be really fun.
So then the requesting client application says, "okay,
well do you wanna give me access to your Facebook friends?"
And that's the protected resource.
Give me access to your Facebook friends,
and I'll let you know,
if they're playing or if they have accounts.
And I, as a resource owner,
because I own my list of Facebook friends,
I say, "okay, sure.
I'm gonna give you permission to access my friends list."
So, I give that permission slip, if you will,
to the requesting client application.
The requesting client presents that permission slip,
to the authorization server, API, and if it's accepted,
and the resource says, "sure, okay, we can do that."
In this case, Facebook.
Facebook would give permission,
to the poker game to get my friends list,
and then we would move on from there.
So that's really what's happening.
I never have to give my Facebook credentials,
to the poker game, right?
I just had to give them permission,
to be able to access my friends list.
Let's dive in a little bit deeper.
So the application requests an authorization,
from the user to access a protected resource.
In my example, that was my Facebook friends list.
If the user agrees,
the application receives an authorization grant,
that's what I was referring to as a permission slip.
Now the application presents its credentials,
and the authorization grant to the authorization server.
Now if accepted,
the authorization server issues a access token,
the application presents the access token,
to the resource server and request access.
And if the token is valid,
the service provider grants access to the resource.
Now, in our illustration, both our authorization server,
and our resource server, were really the same device,
with an API, an application programming interface.
So there you go.
That's SAML and OAuth 2.0 and federated identity.
So that takes us to a three second challenge,
five challenge questions, three seconds each.
Are you ready?
1, 2, 3.
The processes and technologies involved,
in managing user identities, access rights,
and permissions across federated systems.
1, 2, 3.
It's gonna be FIM or Federated Identity Management.
Number two, an XML based open standard,
for exchanging authentication and authorization data,
between a service provider and an identity provider.
1, 2, 3.
And that's gonna be SAML.
Number three, authorization framework that enables
applications to obtain limited access to user accounts.
That's the Facebook and my poker game example.
1, 2, 3.
OAuth 2.0.
Number four, the intermediary that allows
two applications to communicate.
1, 2, 3.
And that's gonna be an API,
an application programming interface.
And lastly, number five, using a single set of credentials
to access multiple resources within an enterprise.
What does that refer to as within an enterprise?
1, 2, 3.
That's gonna be single sign-on,
often referred to as legacy single sign-on.
So that brings us to a security and action,
so we can apply our knowledge.
This one's about website authentication.
Your organization is developing a new secure website.
Now, you are suggesting offloading
the authentication process to a FIM identity provider,
using SAML as the authentication protocol.
So your boss says, "well, that's interesting
but can you give me a practical example of how this works?"
So what might you tell him?
So go ahead and put me on pause.
I gave a little hint there in the other side for you,
about the Google Identity platform,
but come up with any practical example you want.
See what we get, then come on back.
Well, I'd start with asking my boss,
if they've ever used their Google credentials,
to log into a non-Google site.
And my guess is gonna be, absolutely yes.
Well, Google provides a service,
called Google Identity Platform which includes Google,
as the IDP, the identity provider.
Now the Google Identity platform supports SAML.
It allows organizations to configure Google,
as their SAML based identity provider,
enabling users to log into applications,
or services using their Google credentials,
their portable identity.
This would be a great example,
because everybody's really familiar with doing this.
So having this conversation with your boss,
and knowing what examples to provide,
that, my friends, is security in action.
There's your word cloud, not particularly big,
but make sure that you really understand all these concepts
and you can distinguish between what's happening,
with OAuth and what's happening with SAML.
When you're ready, head on over to the next lesson,
and I'll be right there.