>> Just the way Kerberos helps us
>> administer a numeric that
>> makes life much easier for
users by having that single sign-on,
we can certainly see how the same concept,
if extended outside our domain and across the Internet,
how tremendous would it be to
only have one set of passwords
and credentials for all the resources
you access on the Internet.
With that being said, certainly we have to go
back and look at some of the problems with Kerberos.
If your one set of credentials is compromised,
then the attacker has access to everything.
If we can control this process, secure passwords,
and provide a single point of entry,
then that's going to make life much easier for
both administrators and users.
When we do talk about bringing this idea
of single sign-on outside our domain,
we've got to look at a couple of technologies.
One that's most common today is called SAML,
that stands for Security Association Markup Language.
I want you to think about a scenario where
a college student has signed up for
college and they're ready for the first day.
They come in and they're ready
to get their books from the library.
They immediately go in and
register and sign up at the school.
They pay their money and are in.
Next thing the student does
is go to the library and says,
I'm a college student, I need some books.
The library says, we don't know who you are.
The student can bring out a driver's license,
but that doesn't prove that he's part of the school.
What he needs is something that he can show the library,
that he's a valid, legitimate student.
The library says, you need to go to the student center,
get your school ID, and then come back to us.
The student leaves from the library,
goes to student-centered,
and shows his paperwork.
They find his name, he provides his identification,
and he has a badge.
That badge not only says this is
John Smith, but it also says,
this is John Smith, who is
a legitimate student here at ABC College.
Now that he has his badge,
he goes back to the library,
shows his badge, and the library gives him his books.
That badge may have additional information,
things like his major,
so the library pulls a set of books
for biology department for the student.
What information is on the badge
can really change and be very helpful.
What we have here is the idea that
once my student gets a student ID,
they can go to the library or
the cafeteria to purchase meals.
Many entities are going to accept the student badge.
Everything on the college campus is going to accept
that student badges proof that they're enrolled in
the school and can prove their identity.
Now let's say that Uber in town has decided
that they want to increase their business with students.
They work up something that
the university that students can share
their school ID and an Uber will spill a student account.
That requires a trust between Uber and the school.
Then all of a sudden, this one piece of
authentication, the student badge,
is now not just used within that domain,
but now for any organization that's
going to allow a trusting relationship.
The student can use that student
center badge for billing,
for identification,
maybe even participating in laundromat.
Potential for this is really tremendous.
This is what we're trying to achieve when
we bring in federated services
and use SAML or something called OpenID Connect.
What has to happen is
a trusting relationship has to
be built between the organizations
that offer services and the organization that
provides the identifying information
, that student badge.
That's called a federated trust.
We can have trust in an internal environment.
Then taking that and expanding it beyond,
that's going to require this federated trust.
That's exactly what SAML does
and is a part of the role that SAML serves.
A network administrator is
going to go and set up a trust with
an organization or going to provide an identity provider.
Then they're going to be
service providers that provide services.
Ultimately, when this works with SAML,
a user goes to access specific web application.
Let's say you are trying to
access their account in Office
365 or maybe a corporate account on Salesforce or Webex.
I'm going to go
authenticate and say I'm kellyhanderhan@abc.com,
then the application is going to redirect my web browser.
Because they're on abc.com,
you need to authenticate with your own organization.
Basically, I'm redirected to my identity provider.
That can be an internal service that we
set up within our organization.
It can be provided to us from
an identity service provider
if you're familiar with Ping.
When I authenticate myself to the identity provider,
in exchange they issue me a SAML token.
I'm redirected back to
the original application I was trying to access.
Now my web across comes in,
but it has a token.
The trust has already been established
by my administrator.
The application says, I'll take your token.
Now, you're allowed to
access whatever you need to access.
That token is stored as part of
the discussion cookie with the browser,
so that I don't have to keep doing that again
and again for every single service request.
Basically, SAML is going to use a series of
redirects and require a token from an identity provider.
That token from the identity provider is going to go
across a federated trust
and be sent to a service provider.
SAML is slowly being replaced with something
called OpenID Connect, another service provider.
With SAML being bloated,
we're looking to replace it with
something called OpenID Connect.