Single Sign-On with Federated Services Part 1

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

9 hours 49 minutes
Video Transcription
just the way Kerberos helps us administer and a network that makes life much easier for users. By having that single sign on, we can certainly see how the same concept of extended outside our domain and across the Internet how tremendous it 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 of Kerberos like If you're 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, and 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 S I M. L. 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 time
and 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 students 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. A 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 is a valid, legitimate students.
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 over to the student center and shows his paperwork.
They find his name, he provides his identification and he is 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 said the library pulls a set of books for the 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 and 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 with the university that students can share their school ID and then uber will spill the student account
that requires a trust between uber and 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 badger billing for identification, maybe even participating Laundromat.
The potential for this is really tremendous.
This is what we're trying to achieve when we bring in Federated Services and Use S A. M L or something called open ID 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 feathery to trust. That's exactly what s A M. L does and is a part of the role that s a M L serves
a network administrator is going to go and set up a trust with an organization
are going to provide an identity provider.
Then they're going to be service providers that provide services. Ultimately, when this works with S A M L. A user goes through access specific Web application.
Let's say they're trying to access their account in office 3 65 or maybe a corporate account on Salesforce or WebEx.
I'm going to go authenticate and say I'm Kelly Hanrahan at abc dot com. Then the application is going to redirect my Web browser
because you're on abc dot 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 could 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 the issue me A s a m l token,
I'm redirected back to the original application I was trying to access. Now my rub across comes in, but it has a token. The trust has already been established by my administrator, and 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 decision cookie with the browser that I don't have to keep doing that again and again for every single service request.
Basically, as a M. L is going to use a series of redirects and require token from an identity provider. That token from the identity provider is going to go across a federal to trust and be sent to a service provider.
SML is slowly being replaced by something called open ID Connect another service provider
with S A M. L. Being bloated. We're looking to replace it with something called open ID connect
Up Next