An important aspect of security is to match the right permissions to the right people at the right time. In this video, you’ll learn about IAM (Identity and Access Management), account provisioning, permission assignments, single sign-on, and more.
As you’re aware, we use applications on many different systems in many different locations. We have applications that run on our desktop computers, our laptop devices, and our mobile devices. And the data we’re accessing can be located anywhere. It might be locally on that device. It might be in a data center. Or we might store that data in the cloud.
We’ve also got many different kinds of users that need access to different types of data. Employees of the company are accessing data differently than vendors, contractors, or even the customers. From a security perspective, we need to give the right permissions to the right people at the right times to provide them with the access that they need. We refer to this as Identity and Access Management, or IAM.
IAM begins with the process of a user needing access, and it ends with removing that access from the user. This might be a process that occurs during onboarding and offboarding. There’s many times in between where we need to make changes to these permissions. IAM is responsible for determining access control. So when someone starts with the company, they may have a list of priorities. They may need access to email, access to a primary application, and access to the internet.
The authentication and authorization process requires the user to identify themself in some way, generally with a username, a password, or perhaps some other type of authentication factor. And once the user has the access they need, we need to log and monitor all of the access to this data. Not only is this a good best practice for security, but this may be something that is regulated and required based on the organization you’re working for.
This IAM process generally starts with the creation of a user account, and it generally ends when that user account is deactivated. This, of course, commonly happens during onboarding and offboarding. But this might also change if someone was promoted or moves to a different part of the company. If we were to look into the details of the information provided in IAM, we would see that we have a name of a user, any attributes for that user, we have group permissions, and then any other permissions for application access.
This process of provisioning a user and deprovisioning the user account is the core to the IAM process. And it’s one that is required to be assured that the right permissions are being assigned. Not only does this assign the user with the right permissions for them to be able to do their job, but it limits any type of ongoing and extended access. For example, you would not assign administrator access to every person who comes on board in the organization.
One of the primary goals with IAM is to ensure that the permissions assigned to a user are the ones necessary for that user to do their job, and no permissions extended beyond that particular goal. In many organizations, we have mandatory access control where there is a group that is associated with those rights and permissions. So if a new user is hired and they need email permissions, they’re simply added to the email group. Any documents that user creates are private to that user by default.
If someone else logs into that same device, they would not be able to access the files created by the original user. This is an important part of the permissions associated with a user’s rights. And of course, we would limit a user’s access to the core operating system on that device. This not only keeps the user from making any changes to the operating system. It also keeps any third-party applications and malware from making changes to the OS.
Another big part of IAM is verifying who a user might be. We refer to this as identity proofing. There should be a formal process, especially during the creation of an account, to verify that a user really is who they say they are. This process is referred to as resolution, and it’s an important step to ensure that we’re not assigning rights and permissions to someone who should not be on this network. It’s also important that we’re able to obtain additional validation from the user. This means the user needs to provide something that only they know, such as a password, and they might also need to provide additional information, such as the answers to security questions.
And of course, all of this needs to be verified through a process called attestation. This is one where we need additional details to really verify that person’s identity. Many times, this is done through the use of government documents, like a passport or driver’s license, and it might also include an in-person meeting. There are also a number of automated verification options that might look at a user’s credit report and ask specific questions about where a person may have lived or the type of assets that they might have owned.
When a user needs to gain access to a resource on the network, they need to provide some type of authentication. This usually begins with the client sending information into a central point that can be used for authentication. This might be on a VPN concentrator or logging into an Active Directory infrastructure. The user will provide authentication details, such as a username and password. And there’s usually a centralized authentication server that will be used to validate that information. If that login information is correct, the authentication server will send back a notice saying that those credentials have been approved, and the user is then able to gain access to that resource.
If you work in a Windows environment, you’re probably familiar with Single Sign-On, or SSO. This is the process where you would log in one time to the network. And from that point forward, you gain access to all of the resources that you might need, regardless of where those resources may be located. Without SSO, every time you would need to access a new printer or access a different share on the network, you would have to provide your username and password every time.
This is usually on a timer. So once you log in the first time, you may have access to all of the resources you need for 24 hours. After that 24-hour period, you would need to provide authentication again for the SSO to apply. This means that your login credentials and the underlying authorization process have to support SSO.
One common authentication protocol is LDAP. LDAP stands for Lightweight Directory Access Protocol. And it’s a protocol for accessing large directories of data on a network. This is a very standardized protocol. The standard is the X.500 specification. And it was written by the International Telecommunications Union, or the ITU. One of the original versions of this protocol was the Directory Access Protocol, or DAP, and it ran using the OSI protocol.
This was updated to a type of protocol that would work with other operating systems much more efficiently. So it was renamed the Lightweight Directory Access Protocol. If you ever work with LDAP, you’ll see a very standard format for listing out what’s called distinguished names in X.500. And it starts with an attribute, an equal sign, and the value of that attribute. For example, CN, which stands for Common Name, refers to an individual device. And of course, this is built in a way that you can have a structure within the database.
This structure allows you to build a tree where you can organize all of the different devices, users, and other components on your network. These container objects could refer to the country where these objects are located, an organization within that country, different organizational units or departments, and even individual devices within that department. We refer to this as the directory information tree. And each of these individual components in the tree are referred to as leaf objects.
Another standard protocol for authentication and authorization is SAML. This is the Security Assertion Markup Language. SAML allows for the authentication of a user to a third-party database. So instead of maintaining your own database of users, you can simply use one that’s already been created elsewhere. One of the challenges with SAML, however, is that it was never designed for mobile devices. And of course, these days, we use our mobile devices extensively and are often logged in from multiple devices at the same time.
We’ll discuss some other authentication methods in a moment that work a little better when you have multiple devices, especially those that are mobile. A basic SAML process involves three different devices. One would be the device you’re using. That would be the client device, and you’re usually in a browser. You also are trying to gain access to a resource. There’s your resource server on the network.
And the process of authentication and authorization takes place on a separate authorization server. This process starts on the client where the client wants to access a URL on the resource server. Since this user is not logged in, the resource server sends an encrypted SAML request and redirects that to the authorization server. The user then provides user credentials to be able to gain access to that resource, and the authorization server checks those credentials, approves that the credentials were correct, and creates a SAML token.
The client now has a copy of this token that was generated by the authorization server. And now they only need to present the SAML token to the resource server to then gain access to the resource and the application that they want to use. An authentication protocol that was built to work with our more modern and mobile systems is OAuth. OAuth is an authorization framework. And once you authenticate, OAuth determines what resources a user may have access to.
The OAuth authorization framework was built by some of the largest companies in the industry. Since these companies wanted to provide access for all of their users wherever they might be and from whatever systems they may be using, OAuth was the solution. Since OAuth is an authorization framework, there still needs to be something providing authentication. So you often see OpenID used in conjunction with OAuth to combine both the authentication and the authorization.
Here’s an example of an OAuth authorization screen. This is one where we would like to access resources that are located in my Google account, and I want to use a third-party application to be able to do that. In this case, the third-party application is Zapier. To provide this access, I visit my Zapier website and tell Zapier, I would like to use resources on my Google account. Zapier then asks me for authorization to gain access to those resources on my Google account, specifically to see, edit, create, and delete anything that’s in my Google Drive.
Once I click Allow, I’ve now created a link between Zapier and my Google account using OAuth. There may be times when you would like to log in to a resource, but you don’t want to create another account on that particular resource. Instead, you may want to take advantage of federation. Federation allows network access without using a local authentication database. This can be done from many third parties that can then use a separate authentication database for logging in.
You’ve probably seen a screen like this when logging in on a website. You could, of course, use a separate email and password that is local to that site. Or you can simply use your Twitter, Facebook, or LinkedIn accounts on this site to be able to authenticate into that third-party site. For this to work properly, the website has to set up some relationship with Twitter, Facebook, and LinkedIn so that this authentication process can occur. But once that link is made, any users who visit the site can use their existing login credentials on those services to log in to this third-party website.
In this video, we’ve talked about a number of different technologies and a number of different authentication and authorization services. When an organization is making a decision on which technologies they should be using, they have to make sure that all of these are interoperable. Sometimes this interoperability decision is based on what resources you happen to have at the time.
For example, let’s say that you’re installing a brand new VPN concentrator. And looking at the options available on this VPN concentrator, you can see that it does support access to an LDAP server for authentication. If your company already has an Active Directory server or some other type of LDAP server for authentication, that is a perfect match between what the VPN concentrator needs and the resources you currently have available.
Or perhaps you’re installing a new application, and this application uses OAuth as a way of authorization. This means that you’ll need to include some method of providing authentication through an API, or Application Programming Interface, so that you can then pass that information on to OAuth to use for authorization. These interoperability decisions obviously need to be made with a much broader perspective of what the organization is trying to accomplish and what their goals might be for the future.