Single Sign-On with Federated Services Part 2
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Transcription
00:00
>> In OpenID Connect, we have to call
00:00
the service provider, a relying party.
00:00
Instead of an ID provider,
00:00
they are an OpenID provider.
00:00
Really, those are the big differences, same basic idea.
00:00
The way OpenID Connect works [inaudible] is it
00:00
takes a little bit of the weight off
00:00
>> the client browser.
00:00
>> For instance, I'm going to
00:00
try to connect to an organization,
00:00
whatever that service is,
00:00
I'm going to connect.
00:00
Based on how I attempt to connect,
00:00
kellyhand.hand@abc.com, that relying party
00:00
knows who my identity provider is.
00:00
Again, that's set up by the administrator.
00:00
Instead of redirecting the client's browser,
00:00
the relying party challenges
00:00
the OpenID provider and says,
00:00
is this person legit, can we trust them?
00:00
The OpenID provider sends back to
00:00
an OpenID token that provides that authentication.
00:00
Then ultimately, the relying party is going to
00:00
be able to provide the services to the end-user client.
00:00
We still have that back and forth step-by-step process,
00:00
but ultimately, it's about
00:00
the trust relationship between the relying provider,
00:00
or the relying party and the OpenID party,
00:00
just like it was between the SAML service provider,
00:00
and the SAML ID provider.
00:00
It's all about this trusting relationship.
00:00
The big benefit is the user logs onto
00:00
their identity provider and they're not
00:00
sending authentication information across the Internet.
00:00
No username and passwords go across the network,
00:00
just the SAML tokens that would not
00:00
be valuable in any way to an attacker.
00:00
Single-sign-on where their identity provider
00:00
uses tokens to vouch for authenticity.
00:00
This is the direction that we're going out on the web.
00:00
One other element that's part of
00:00
OpenID Connect is called OAuth.
00:00
We're on OAuth Two. This is just simply a framework.
00:00
It isn't a specific protocol or a type of API.
00:00
It's a framework that we designed our applications on,
00:00
so you can delegate rights or
00:00
actions to specific applications.
00:00
For instance, let's say that I
00:00
want to go to Spotify and listen to music,
00:00
and asks me, would you like to use
00:00
your Facebook account to login?
00:00
If I say yes, Facebook is actually
00:00
>> my identity provider.
00:00
>> Facebook is sending me a token on behalf
00:00
of Spotify to validate my identity,
00:00
and to authenticate me.
00:00
Usually, I get a little message that pops up and says,
00:00
would you like Spotify to update your Facebook page so
00:00
your friends can know it music you're listening to?
00:00
When I click "Yes",
00:00
that's giving an application the right
00:00
to modify another application,
00:00
and the right to modify Facebook is only mine.
00:00
I'm the owner of the Facebook page.
00:00
I'm the only one who's allowed to update the page.
00:00
I've just delegated that right for
00:00
Spotify to do something on my behalf.
00:00
Same idea, if I'm doing
00:00
accounting and I log into QuickBooks,
00:00
one of the features of QuickBooks is they can pull
00:00
your credit card information
00:00
from your credit card companies,
00:00
they can pull your bank statements,
00:00
they can pull all financial information.
00:00
Of course, you have to give it permission
00:00
to do so. That's OAuth.
00:00
That's the ability to act on my behalf in order to
00:00
increase usability and interoperability.
00:00
It winds up being very valuable.
00:00
This is a framework on
00:00
which we're designing applications.
00:00
The whole goal here for single
00:00
sign-on and federated trust is to
00:00
take some of these ideas that we
00:00
just take for granted in a local domain.
00:00
I just take for granted,
00:00
I log on to the domain,
00:00
and then it can print to my printer,
00:00
access a database, or whatever I need.
00:00
What we're doing with SAML and
00:00
>> OpenID Connect is they're
00:00
>> both serving the same purpose of
00:00
logging onto identity provider.
00:00
As long as our administrator sets up
00:00
the proper federated trust,
00:00
we can log in once to that identity provider,
00:00
and then access all the resources that
00:00
has trust, whether they're local,
00:00
or in another organization,
00:00
or anywhere across the world,
00:00
as long as the trust has been set up.
00:00
It is going to expedite administration
00:00
>> and make it easier
00:00
>> for admins to have tighter control of
00:00
what users access what resources.
00:00
It's also going to make life much easier on users,
00:00
because they won't need to keep up
00:00
with so many passwords.
Up Next
Similar Content
