From the course: CompTIA Network+ (N10-009) Cert Prep

Single sign-on (SSO)

From the course: CompTIA Network+ (N10-009) Cert Prep

Start my 1-month free trial Buy for my team

Single sign-on (SSO)

“

- We live in a world where we all want to get on tons of computers. Think about it. During your usual browsing, you visit all sorts of different websites. Those are real computers you're accessing. Sure, the web can be a bit tricky since it's so public, but we can easily add usernames and passwords to sites that we want. People don't do it a lot, but it's totally doable. Let's look at a better example. Think about a local area network. Here at Total Seminars, we've got tons of computers, servers, and we're all people who are just sharing stuff, whether it's printers or other things. Well, a lot of these things, I want to access. In a typical Windows work group, here's how it works. We've got three or four computers, a printer, and whatever else we need. Each computer has its own username and password list, and it works like a charm. The problem is that if I want to get into a computer, I need a username and password specifically for it. And if I want to access another computer, guess what? That's right, it might have a different username and password. So Windows work groups, which have been around forever, are pretty handy. You can log into individual computers easily, but sometimes you need to log into a bunch of computers all at once. You go from one computer to another, and soon enough you're thinking, "I can't keep track of all of these passwords." Well, so this is what you're going to do. You're going to figure out if you can cheat. Well, what would that look like? Well, let's take a look at this example again. I could just use the same username and password on all the different computers in my local network. That way, I wouldn't have to log in every time because once I'm logged into my computer, it would automatically recognize me on the other computers too. But here's the thing, that's a terrible idea. It's a huge security risk and a major problem. So what's the solution? Well, we can use single sign-on instead. Single sign-on is all about logging in once and having access to everything else automatically. It's a cool concept, and it works differently depending on the context. Let's start with the classic version, single sign-on for a local area network. To make this happen, we need Windows Active Directory. It's been around forever, and it's the go-to tool for single sign-on in local networks. While it can do more, we'll keep it simple just for now. First, you'll need to buy a copy of Windows Server and set it up on your network. Picture this, you've got your Windows Server and all these other computers connected to it. Next, you create a domain, which is what we call it in the Windows world. Then, an admin has to manually join each computer to this domain. That means someone you trust goes one by one linking each computer to the domain. Once that's done, we've basically created a trust situation. When the admin connects each computer, we've set up what's called a federated system. Think of federated as trust. There's an implicit trust developed because of Microsoft's Kerberos-based authentication system. In the end, we've established trust across the network. So when we talk about LANs, Active Directory is the go-to for single sign-on. There's another type called SAML as well, which is totally different, and we're going to get to it. So picture this. Let's say I'm in Texas running an oil pipeline with loads of pumps, thermometers, cameras, and all sorts of gadgets. We've got web apps for each one of these devices so that I can control them, but they're super secure, so don't worry. It's crucial for me to access these securely at any time. With hundreds of web app devices, I want to log in once and be set across all of them. That's where SAML kicks in. It's mainly for web apps and lets one user log into multiple devices without any fuss. Imagine my oil pipeline with devices accessible through my VPN. I don't want to keep logging into each pump or camera separately, that's what SAML solves. It starts with something called an identity provider. So that's going to be a system out here that everyone can chat with. I'll log into the identity provider, and all of these web apps are called service providers. This means I can jump between them because the identity provider gives me a token to access any of these devices as registered service providers. One of the main protocols in Active Directory is LDAP, Lightweight Directory Access Protocol. It was made to help applications quickly grab data. While LDAP itself isn't tied to any specific product, Active Directory uses it to let LDAP-based apps access its structures. Active Directory works better when split into forests and domains rather than a single big user community. LDAP shines when lots of users need to log in all at once. It's also handy for single sign-on methods. SSO with LDAP boosts security and efficiency, and often improves user experience. But that's more due to the SSO than it is to LDAP. So how does SSO with LDAP stack up against SSO with SAML? Both LDAP and SAML are authentication protocols, but they have different roles. LDAP is all about in-house or on-premise authentication. On the flip side, SAML shares user credentials with web apps and cloud services. And while LDAP aims to be the main authority for user identity, SAML acts as a supportive player in the identity and access management game, otherwise known as IAM. So when we chat about single sign-on, especially for the test, think about what kind of security you actually need. Like if it's local network where you just want to share folders and files, you're probably going to use Windows Active Directory. Sure, there are other options, but Windows Active Directory is pretty much the go-to.

Contents