-: We've talked about a lot of different identity systems.
And in this final identity lecture,
I wanna talk to you about federated identity systems.
So, what is a federated identity system?
Well, this is an identity system that's gonna
move the trust boundary outside your organization.
It's gonna give it to some third party.
Somebody like Google, or Facebook, or LinkedIn.
Or any of the other identity providers out there.
For instance, if your website allows you to login
with your Facebook ID, that is using
a federated identity system.
Now, when we talk about a federated identity system,
it's made up of three parts.
There's the IDP, which is the identity provider.
There's the RP, which is your relaying provider,
or your service provider, depending on the terminology
used by that federated system.
And there's a consumer or user.
Now, we talk about the identity provider.
This is the person who provides the identity.
So, in our example, Google, Facebook, LinkedIn.
One of those companies.
And they release the data to relaying
partners as part of the authentication
or directory services they're providing.
Now, the relaying party, or service provider
is a member of the federation.
And they are gonna provide the services
to the end consumer or user.
And this is gonna be, once they've
been identified by the identity provider.
And finally, you have a consumer or user.
And this is the person who is asked
to make a decision whether or not
to share their information from the directory.
And their ID.
To this relaying provider, by the identity provider.
Or, they're the ones who are gonna get
services from a relaying provider or service provider.
So, that's a whole lot of words.
What does it really look like?
Well, here in this diagram, you can see what it looks like.
If I'm the user, I'm gonna go to my
relaying provider, the website I wanna access.
And I'm gonna say, hey, I wanna access
your website using my Facebook credentials.
There they're gonna do a discovery phase over to Facebook.
Which is the IDP.
Facebook is then gonna validate it,
and send it back to the relaying provider.
If those two things mesh, the relaying provider
will create an account for me.
Using an associated, that Facebook
is my authentication provider.
And I will get an account on their service
in the relaying provider, that allows
me to login with my Facebook credentials.
There they're gonna register those relaying
party attributes across the two systems.
And then we have this federation that takes place.
Between their site, and Facebook.
That allows me to use my Facebook ID
to login to the service provider.
In this case the relaying provider.
Now, how do you choose a federated ID system?
Should I go with Google?
Or Facebook?
Or LinkedIn?
Or should I use something else altogether?
Well, do you care if the user is who they say they are?
In a lot of cases, you don't.
You just wanna know they have a valid email address.
And Facebook can give that to you.
Google can give that to you.
Right?
So if not, you can use Google, Facebook, LinkedIn, etc.
Now if you really wanna care who the person is,
you might wanna use a different provider
that will go through vetting infusers.
And there are some providers out there
that will actually require you to send in identification.
Like your driver's license.
To prove you are who you say you are.
When users sign up for your site,
using federated ID, you immediately
can provision an account for that user,
based on the information you got from the identity provider.
Their name.
Their address.
Their phone number.
Their email.
Whatever those things are that they
have authorized you to get.
So anytime you see that login with Facebook button,
remember, you're using a federated ID system.
Now, there's different technologies
used for federated ID systems.
There's SAML, which is a Security Assertion Markup Language.
There's OAuth, OAuth 2.0, and OpenID Connect.
Which we've talked a little bit about already.
And then there's another one called
Active Directory Federation Services.
Which is ADFS.
Which is Microsoft's jump into
the federate ID systems realm.
We'll talk about each of those here.
SAML, or Security Assertion Markup Language,
is an XML-based language that sends authentication
and authorization between the ID provider
and the relaying provider.
It's another way to transfer that data back and forth.
This is used to enable single sign on
for web apps and services.
So you can see here in the diagram,
that the user, when they go to the web browser,
is what's called the user agent.
Now when I try to login to one of my services
using single sign on, it's gonna request
the resource from the service provider.
The service provider doesn't really know who I am.
So it's gonna go back to the identity provider
saying, who is this person?
Do they have access?
The identity provider will say yes or no.
Who the person is.
And then they can go back to the service provider.
Give me access.
And give that back to my web browser.
All this happens behind the scenes
and you don't even have to see it.
Because SAML takes care of it for you.
This allows for attribute, authentication,
authorizations to be made and exchanged
between an identity provider and a service provider.
Now, the next one we talk about is OAuth and OAuth 2.0.
This was deveoped by the Internet
Engineering Task Force as an opensource solution
to provide authorization framework to allow service
providers to access web-based, or HTTP-based services.
This provides access delegation to allow service
providers to provide actions on behalf of their users.
So, I as a user, go to a website.
That website then can allow that identity,
Facebook, LinkedIn, Google, to allow me to login
using that identity from the third party website.
Which is the ID provider in this case.
This is gonna support web clients, desktop,
mobile devices, and other embedded types.
OAuth and OAuth 2.0, because it's opensource,
it is widely available at a range of services.
From a range of clients.
Now, there are four parties that
are served inside of an OAuth authorization here.
There's clients, resource owners,
resource servers, and authorization servers.
Clients are applications that
the user wants to access or use.
So if I go to a particular website,
that website is the client.
I'm not the client.
Okay?
There's resource owners.
This is the end user who's being serviced.
That's me.
Why am I considered the resource owner?
Well, because I am the own who owns my identity.
Now, the identity provider is going to give
that out on my behalf, but I own
the decision of whether or not they can do it.
Then there's the servers that I wanna access.
These are called the resource servers.
So, if I wanna access a Flickr for instance.
I can login with a Flickr account, or maybe a Yahoo account.
Right?
And this is the server I wanna access.
That is my resource server.
It's providing the service that I the user wanna get to.
Through my client.
This gets a little confusing right?
And then there's the authorization server.
And this is where the IDP comes in.
This is the servers owned by the identity provider.
So in this case, if I was talking about
using my Yahoo login to get into Flickr,
that would be using my IDP of Yahoo
to get onto the resource server, Flickr.
Through my web browser, the client.
And I am the resource owner.
Right?
Now, for the CSA Plus exam, you're probably
not gonna see a whole lot of in depth
questions on OAuth or OAuth 2.0.
You probably don't even need to know
these terms really in depth.
I've never seen a question on'um.
But, I wanted to make sure you covered'um,
because they are under the exam objective.
So, there's a possibility you'll get
a question on'um, but not really likely.
So now, we put all that together,
and here's an example using Flickr.
This is a Flickr federated example.
Because, you can use your Flickr login
to get to lots of different applications.
So, the application I go into, which is the client.
Is gonna request from Flickr, the identity.
It's gonna come over to the user to say, am I allowing that?
As the resource owner.
And if I say yes, it's then gonna tell Flickr that's okay.
Flickr will then give that back to the client.
Who can then turn around through the resource server.
And get the services that they want.
The last one of these technologies
I wanna talk about is the ADFS.
And this is Microsoft's entry into the game.
It's Active Directory Federated Services.
Microsoft wants to get into the game
just like everybody else.
And so they created a federated identity using ADFS.
Now, this is gonna provide authentication
and identify data as claims to service providers.
Just like OAuth does.
This is gonna allow partner sites to use trust policies
to match their claim to the claims supported
by those services to make authorization decisions.
Just like OAuth does.
Sounds very similar right?
This works just like OAuth in almost every single way.
But it's Microsoft proprietary technology that's being used.
You might have seen your Microsoft account is a login
that can be used on multiple services.
That's because of ADFS.
That's what's allowing this to happen.
Now, we talk about federated systems.
They're great.
You can use one login at multiple different places.
Without having to signup for accounts
on each and every different website.
And remember a bunch of passwords.
That's all great.
But what happens when it's time to do an instant response?
Well, who's responsible for it?
Well, the first thing you need to do
is check your contract if you have one.
If you're using a Google or a Facebook,
those are all opensource.
And openly available.
There's no contract.
But if you have outsourced this federated
systems to an ID service provider.
Or if you're using like ADFS to a commercial
Microsoft contract, you might have a contract for that.
So check it.
It should say in there who's
responsible for the instant response.
Now the IDP, the ID services provider, is normally gonna
be responsible for notifying account owners.
Which are the users who have their accounts.
So, if Facebook gets hacked, Facebook should
notify its users that it got hacked.
Right?
But they have responsibility to notify us,
those who own websites, the RPs or SPs in this case.
The search providers or relay providers.
That there was a breach.
Because I need to do some stuff on my system
to say, hey, those old Facebook logins are no longer good.
And I have to reset those.
Okay?
So I can do things like password resets.
They're also gonna tell us what the required response is.
And that's gonna be on the IDP again.
So if Facebook got hacked, Facebook should tell us
what is the required response.
Hey, they required response users
is all of you need to reset your passwords.
All of you need to reauthenticate.
Whatever it happens to be.
Now, the relaying provider and service providers
should determine their own response.
So, if I heard on the news that Facebook got hacked.
And I use Facebook as my federated identity system.
Now I have to decide what I am gonna do
on my server to protect myself.
Am I gonna disable all logins from Facebook?
That may be an action.
Right?
It doesn't have to be.
But it's your choice as a risk
analysis decision that you're gonna make.
If your user accounts are compromised,
how are you gonna provide them continued access?
So let's say I relied on Facebook logins
for all of my users to access my online training courses.
Well, if Facebook got hacked and I decide,
I don't trust Facebook anymore.
Turn off all the Facebook logins.
Well, how are all my people gonna get in now?
Ooh.
That's gonna be a problem.
So these are some of the challenges when you
choose a federated ID system that you have to think through.
What happens.
There's good benefits.
But there's also some bad things
that you have to think about.
And how you're gonna deal with those as you move forward.