The authentication process is an important part of any infrastructure. In this video, you’ll learn about single sign-on, RADIUS, LDAP, SAML, and other authentication technologies.
Many of us are very familiar with the process of authenticating. We put in a username, a password. Sometimes there’s an additional authentication factor. And that provides us access to a system. But behind the scenes, there is a lot more happening. So let’s dive into the process of authentication.
The process of authentication uses something called the AAA framework. We’ll look at all three of the A’s associated with the AAA framework in a moment. But first, we start with a piece of information that everyone has access to, and that would be the identification that we use when we’re logging in. This is often our username. It might be an email address. But it’s information that is usually available to pretty much everyone. This is public information.
And just because someone happens to know our email address or happens to know our login name does not give them access to our systems. The first A in the triple a framework is authentication. This is the process where you prove that you are really who you say you are. This is often done with some type of private information, such as a password or some other type of authentication factor.
Once you go through the authentication process and you prove that you are who you say you are, we now need to be sure that you’re provided the access associated with that particular user. This is provided through the second A in the triple a framework, Authorization. We need to be sure that you’re provided the proper access to files, directories, or areas of the network based on who you say you are.
And of course, we need to be sure that we track the people that are logging in and the people that are logging out. We do that through the third A in the AAA framework, or Accounting. We want to be sure that we document when someone logs in, logs out. We also want to be sure that we document when someone does not complete the authentication process properly. There might also be other pieces of information associated with identification, authentication, or authorization that we might also store as part of this accounting process.
There may be many different processes that occur behind the scenes when you provide your username and password, but let’s look at a very common scenario where we’re logging in to a VPN concentrator from somewhere out on the internet from our laptop. We will need to send this VPN concentrator information about who we are.
We need to provide a username, a password, or some other type of authentication factor. This is usually sent to a AAA server, which contains all of this username information, stored passwords in a protected form, and anything else that can help prove that we really are the person we say we are. If the information that we’ve provided matches what’s contained on the triple a server, that server will send a message back saying that those credentials have been approved. At that point, we’re able to traverse the network because we’ve gone through the entire authentication process and we were confirmed by this AAA server.
On many networks, we only have to provide that authentication information one time during the day. And from that point forward, we can access all of the resources that would normally be accessible to us. We refer to that one-time process as a single sign-on. When we sit down at our desk in the morning, we provide our username, our password, any other authentication details required, and from that point forward, for the rest of the day, we don’t have to provide that information again.
We obviously don’t want to provide that access indefinitely, so there’s usually a time frame associated with this, often 24 hours. So when we step back into the office the next morning, we will probably have to go through this process again. Single sign-on is a function that is directly associated with the authentication process, and not all authentication methods support single sign-on. So you’ll want to check with the authentication method that you’re using to see what options might be available for SSO, or Single Sign-On.
One very common protocol used during the authentication process is the Remote Authentication Dial-In User Service, or RADIUS. RADIUS has been around for a very long time and is supported on many different operating systems and many different devices. And although it has the word “dial-in” in the name of the protocol, it is a protocol that can be used on our modern networks as well. So when someone is logging in to their VPN concentrator, their concentrator may be communicating to the AAA server using the RADIUS protocol.
This could also be used for other authentications, such as authenticating with a server or logging in to your wireless network using 802.1X. And because RADIUS is so well supported across so many different operating systems, it’s common to have this as an option on most authentication systems. So if you’re installing a new VPN concentrator or a new firewall, you may see RADIUS as one of the options available for authentication.
Some authentication databases are effectively a list of usernames and passwords. And although that can be a useful way to store authentication details, it doesn’t tell us anything about who that user might be or where they might be located. To provide additional context, we might want to use a more capable way to reference these details. For instance, we might want to use the Lightweight Directory Access Protocol, or LDAP.
LDAP is a way to read and write information from a centralized directory on the network. This is very similar to a phone directory or a phone listing where you could search for users. You could look up different departments, and you can find information based on a phone number. LDAP is also a well-established standard. It was created by the International Telecommunications Union, or ITU, and it uses a standard known as X.500.
The original version of this protocol was known as the directory access protocol, and a lightweight version of this protocol was created, and we put the L in the front to designate this as the lightweight version. So if you’re using Windows Active Directory, you’re logging into an Apple OpenDirectory system, or a Novell EDirectory, then you’re probably using the Lightweight Directory Access Protocol, or LDAP.
I mentioned that LDAP allows us to add additional context to a particular user or particular device. We do this by using the standard known as X.500. X.500 allows us to associate attributes to a user or to a device. For example, let’s say that we have a web server. Obviously, this web server has a name. It may be called WIDGETWEB. And by itself, we know that we can use that name to reference that web server.
But it would be nice to have more context about where that server was located, who owns that server, and where that server might be maintained. So we might add additional attributes to that particular server’s name. For example, we could add an organizational unit name. This particular organizational unit is Marketing, which means this web server is managed by the marketing department. It may be part of a larger organization known as Widget. That organization may be located in London. And it may also be part of the widget.com network.
Having this additional context allows us to understand where the server might be located, who manages the server, and where we can go to find out more information about that particular device. With these attributes, we can now start to build a hierarchy of information associated with that device and all of the other devices and users in our network.
We can then build a tree containing these objects that we’ve built in our LDAP database. We might be dividing this particular database up by different countries. These different countries might have different departments within them. And ultimately, you might have individual users or individual devices that will be part of that tree. We refer to these higher-level objects as containers, and the individual users and devices would be leaf objects. This means during the authentication process, we can provide a lot of context about exactly who may be logging in and where they may be associated in the overall scheme of our organization.
One open standard for authentication and authorization is known as SAML. This stands for the Security Assertion Markup Language. One of the goals of SAML was to make the authentication and authorization process open so that we can then apply it to many different types of applications. One of the challenges, though, with SAML was that it was not built for mobile devices. So if we need to authenticate to a device, we may need to do that across multiple devices if we need to use them all simultaneously.
The authentication flow with SAML is a little bit different than the flows we’ve seen earlier. There’s usually three different components associated with the authentication flow. There is a resource server, there’s the client, which is usually you using a browser, and there is an authorization server. When a user tries to access a resource on a server and they don’t already have authentication, that resource server will redirect that client to communicate to an authorization server to be able to gain access.
Username and password information is then passed to the authorization server. It’s confirmed through those processes we spoke of earlier through an LDAP database or RADIUS. And then if that information is successful, a token is generated and provided to the client. The client then proves that they’ve authenticated by presenting that token to the resource server, and the server will confirm that based on the cryptographic signatures and then provide an access granted information back to the client.
And one of the last authentication protocols that we’ll look at is known as TACACS. This is the Terminal Access Control Access-Control System. This is another authentication protocol that’s been around for quite some time. It was originally used to control access to dial-up lines over modems at ARPANET. The latest version of TACACS is known as TACACS+, and it’s one that was very commonly associated with Cisco devices. And even today, people consider TACACS+ to be a very Cisco-centric authentication method.
However, many aspects of TACACS and TACACS+ were made public in an open standard in 1993. And today, anyone should be able to integrate TACACS+ within their authentication system.
It’s very common during the authentication process to provide login details such as your username and your password. But of course, someone else could have access to that information. So very often we have other authentication factors that we need to provide. When we’re adding additional factors to the authentication process, we refer to that as multifactor authentication. This means we may need to provide a password. There might be a mobile app with a particular number that we need to provide. Or we might be including GPS details that show that we’re located within the corporate facility itself.
Some popular multifactor authentication factors might be something you know– that might be a password– something you have– that might be your mobile phone with the app that you’re using. It might be something you are, such as a biometric reading, for example, your fingerprint. Or it might be somewhere you are, which would certainly be a GPS location. One or more of those could be used during the authentication process to help prove that you are really who you say you are.
The factor of something you have is often associated with a TOTP. This would be a Time-based One-Time Password algorithm that is integrated into an app that you might have on your mobile device. This usually has a secret key associated with it, and it uses the time of day to be able to provide what is considered to be a pseudorandom type of numbering system. This number tends to change occasionally. So every 30 seconds, you may get another randomized number that appears on the screen. In reality, this is not a randomized number. It’s a number that only seems to be random, and it’s a number that is expected by both sides of the authentication process.
This is accomplished by creating a secret key ahead of time and then synchronizing both the client and the server using a protocol such as the network time protocol. So during the authentication process, you may be asked for your username, your password, and then the code that appears in the app on your mobile phone. This is becoming a very common way to authenticate, and it’s one that’s used by Google, Facebook, Microsoft, and many other organizations to add additional factors to the authentication process.