Identity Controls – SY0-601 CompTIA Security+ : 3.7

Verifying the identity of a user is an important step in the authentication process. In this video, you’ll learn about identity providers, certificates, tokens, and SSH keys.


When you have an application that’s running on your local network you probably have a pretty good idea of what users and what devices will be accessing that application. But if your application is running in the cloud you may not have that level of visibility into exactly who’s connecting. In those cases, you may want to control the identities through the use of an identity provider or IDP. This is a service that can vouch for who a person happens to be.

You can think of this as being authentication as a service because this is a third party providing this type of identity control. This IDP will be responsible for identifying and controlling users based on who the user name might be and what devices they might be using. This is commonly used for cloud based applications that need single sign on or some type of authentication. And it’s more useful to have a third party provide that than to have to recreate and manage that process ourselves.

Fortunately, there are many standards available that can help with this identity control, including SAML, OAuth and OpenID Connect. To be able to understand a particular person’s identity we need to gather a number of attributes associated with that person. Combining these attributes together allows us to understand and identify a particular entity.

For example, a common attribute you can associate with an individual who may be working in your organization, may be their name, their email address, their phone number or their employee IDed. We could also add other attributes to this as well that might help us with the identification, such as what department they happen to belong to, their job title or what their mail stop might be.

We could use just one of these attributes to be able to identify someone. For example, we could use a name. But there may be cases where you have different employees who have the same name. In those cases, we may want to add on additional attributes such as an email address or phone number to be sure we know exactly who that user might be.

We can also take advantage of public key cryptography to help identify who a person might be through the use of certificates. This digital certificate is assigned to a person or assigned to a device and it allows us to confirm that the owner of that certificate is someone that we can trust.

The certificate owner might also be able to perform other cryptographic functions with this certificate. For example, they can use this for encrypting data or to create digital signatures that can be trusted by a third party. This type of identity control requires that we put in some type of public Key Infrastructure or PKI. And this normally would also include a certificate authority or CA.

The CA is the central trusted entity for all of these digital certificates. And the CA is usually digitally signing these certificates when they’re deployed. We can also put these certificates onto smart cards that can also double as identification cards. We would slide this card into the device that we’re using to provide authentication and we’re usually providing a personal identification number along with that. Or if the device we’re using doesn’t have a smart card reader we might want to use a USB key and put the certificate on the USB drive itself.

During the authentication process, the USB key is plugged in, the certificate is read and usually works in conjunction also with a personal identification number. If you’re a server administrator, a network administrator or you work on the security team you’re certainly using secure shell or SSH.

Secure shell allows us to get this command line prompt on these remote devices. But instead of using a username and password we might want to use public and private keys to be able to provide this authentication. This will be especially important if we’re doing any type of automation since we usually won’t be there to type in a password while this script is running.

One challenge with allowing key based authentication is the management of these keys themselves. We want to be sure that there is a centralized way to be able to manage all of these private keys and that will allow us to both control the keys and audit the use of those keys. There are many options available for us key management both on open source and on the commercial market.

If you have your own lab and you’d like to use this public private key pair for SSH authentication instead of using your username and password it’s a relatively simple process. If you’ve not previously created a public private key pair you can do that by running the ssh-keygen command, this is usually one you’ll find in Linux or Mac OS.

If you’ve installed the open source package or it’s one that’s already installed in your Linux distribution, then the SSH keygen command is probably available on your system. After creating that public private key pair you would then copy the public key to the SSH server using the SSH copy IDed command.

And once you have your publicly key deployed to the servers that you’re connecting to you only need to simply SSH to the user at host. And then it will login without any type of password authentication.

Here’s what this process would look like. Let’s first try to SSH to my local server as root. And the server name is 10.1.10.170. It then prompts me for a password and if I type in that password I now have access to that server.

Let’s now create a public private key pair. Let’s push our public key to the server and let’s see what difference that makes during the authentication process. To create the key pair I’ll simply run ssh-keygen. And when I do that it asks what file I like to save the key will use the default file.

If we want a passphrase we can put a passphrase in here or we can leave it empty. I’m going to leave this one empty, it asks for the same passphrase again. And shows me that the IDed has been saved in the particular file on my system. Now I have a public private key pair and I can start deploying that public key to all of the servers that I’d like to use to automate this identity process.

Now that we’ve created a public key and a private key. Let’s push the public key to the server. And we’ll of course, keep the private key private on our machine.

I’m going to use the SSH copy IDed command. And undo that to route at 10.1.10.170. It says that the source of the key to be installed is the one that I have at id_rsa.pub. I’m attempting to login with those new keys. And it asks for a password. So let’s put our password in for that server and it says that the number of keys added is one.

Now it says try logging on to the machine with that command to see if that key has been added properly. So let’s do that. Let’s use SSH and route at 10.1.10.170. And now I’m logged in to that server without using any password during the authentication process. Instead of a password it used my public key on that server to confirm that the private key on my local machine is indeed the correct one. And using that as the identity it provides me access to the machine.

If someone else tried to use this SSH command it would not authenticate automatically using the public private key because no one else has access to the private key. That key is only available on my local machine.