Single Sign On

Video Activity

In this lesson course, participants will become familiar with the concept of a secure single sign-on (SSO). In the early days of information technology, someone may have to sign on to multiple systems individually using distinct credentials, creating time inefficiency and the potential for information insecurity through the use of simple passwords,...

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 »

Time
3 hours 54 minutes
Difficulty
Advanced
CEU/CPE
4
Video Description

In this lesson course, participants will become familiar with the concept of a secure single sign-on (SSO). In the early days of information technology, someone may have to sign on to multiple systems individually using distinct credentials, creating time inefficiency and the potential for information insecurity through the use of simple passwords, or by writing passwords down. A domain structure is based on the concept of single sign-on (SSO). In SSO; the user provides credentials in return for a token, which will contain a list of the groups you have membership in. When you access a device your token (your group memberships) are compared against the access control list on that device; if you are on the list, then you'll be granted access to the device. SSO pros:

  • Ease of use for end users

  • Centralized control

  • Ease of administration

SSO cons - Single point of failure

  • Standards necessary

  • Keys to the kingdom (if someone gets access to a password then they have access many resources)

Technology is moving toward the concept of a super sign on: we log in to one authentication server and we get an authentication token that is capable of traversing trusts throughout many different domains/organizations.

Video Transcription
00:04
okay, Another idea for a secure environment. Secure, single sign.
00:11
And this goes back to the time or, you know, really to appreciate the significance of single sign on Let's go back years and years ago toe and were prevalent in smaller networks. Have you had a network of 5 10 systems almost assuredly they were set up
00:30
in a peer of your network.
00:32
Well, if I'm connected to System A, I need a set of log in credentials to connect the system. Eh?
00:39
That I will print to a printer on computer B. I need log in credentials there. And for every system that I'm gonna access, I'm gonna need a set of credentials for that particular system. And that was the issue with a peer to peer network. And so I might have 10 other computers, 10 sets of credentials.
00:58
So I'm either going to write those username and passwords down user names
01:03
or I'm one tiu choose easy passwords, or I'm gonna use the same password for all the resource is. And ultimately, if that's the case, I'm gonna do some very unsecure things with password management.
01:17
So
01:19
we shifted over to the client server environment.
01:22
So I provide my log in credentials to an authentication server and in exchange for those credentials they give me are in exchange for that long and information, I get a token I'm granted to token that resides with me throughout my duration of the log in to the domain. And that's really what a domain structure
01:40
is based on. Is this idea of single sign on
01:44
and release force. That token goes that tokens simply contains a list of the groups which I'm a member.
01:52
Ah, so when I go to access printer, be my token. My memberships are compared up against the access control this on that printer. And if it says sales came on on the sales team and I have full control of the printer, Well, that's Max matched up against
02:09
the access control list on the printer,
02:13
and I'm granted access. Okay. Actually, basically, the token would say I'm on the sales team access control list on the printer would see sales team full control. Okay, so that authentication took and resides with me. I don't have to continue to provide credentials. I can simply provide my credentials one time.
02:31
Hence the name single song.
02:34
Okay, now the benefits of that much easier for end users. Obviously, um, centralized control and management of passwords so I can enforce it. Good. Robust password policy on my servers. Now again. Not foolproof, but it's a step in the right direction.
02:53
Um, single sign on environments are easier to manage. We can use those. When you look in the policy, you know, there are a lot of advantages
03:01
now, the downside, of course, to a single sign on environment is this idea of keys to the kingdom. Meaning okay, if one password were great. Me access to all the resource is in my domain.
03:14
If somebody gets that one password they have access to all the resource is so that's definitely true. But ideally, with well trained users and good password policies in place will mitigate that best.
03:27
And as a matter of fact, what we're moving towards today is this idea of super sign up. So we logged onto one authentication server and we get this authentication token that's capable of traversing trusts throughout many different domains in many different organizations. This is the idea that,
03:46
um
03:46
allows you to log on to numerous. Resource is with your social media accounts. Maybe your Facebook account or Twitter,
03:53
you know, like so if I'm gonna go on by
03:57
plane tickets at Southwest Airlines rather than having to create a user account there, I can simply Logan is a Facebook user, and my credentials are passed across that that trust that's been created. Sometimes we refer to those as Federated Trusts. So we have the same problems, but on a much larger scale,
04:16
right,
04:17
you know, definitely easier for user's cuts down on user names and passwords, I've gotta remember. But ultimately, you know, keys to the kingdom, you know, exponentially increased with all these different resource is once that social media account, those potentials get compromised.
04:36
You know that the numerous domains on numerous organizations, my credentials air compromised across all across all of these
04:46
now very popular single sign on technology. So getting away from Super sign on, let's go back to the domain environment. Curb Rhodes is a very, very popular single sign on technology. Today it was developed for UNIX. Most UNIX systems still use it in a network environment.
05:04
Windows 2000 and up. So that's been quite a while ago. Windows 2000.
05:10
It was the first Microsoft system to use Purple Rose. But it's very much in use today.
05:15
It's ticket based, so users ultimately you're branded tickets to access. Resource is and those tickets provided mean evolve in a means of authentication, lots of different elements. And as a matter of fact,
05:30
ah, Kerberos is quite complex. Although you can certainly get a simplified overview of curb Rose in the C I S s P domain for access control.
05:44
There's a little commercial for the C I S S P course, but ultimately, Kerberos is about taking those credentials from a user and in exchange for those credentials, giving the user what's referred to as a ticket ranting ticket.
05:58
And that ticket granting ticket proves the usual was authenticated. So it sort of verifies the fact that, okay, they've provided the correct user name and password. Now, every time that they want to access a service, that ticket raining ticket is sent to the ticket raining server and they're granted a ticket
06:15
that says the resource so very heavily ticket
06:17
base, the key distribution center really is the heart and soul of perp arose because what makes up the key distribution center is the ticket raining server and the authentication servants and those
06:33
our first work. Which means from now on I'll stand of service standpoint. The distribution center will be great. So
06:45
Scarborough Shoes is symmetric encryption, so there's no need for certificates or public infrastructure. So, like I said today,
Up Next