The authentication process is critical for maintaining the security of our data. In this video, you’ll learn about security assertion markup language (SAML), single sign-on (SSO), just-in-time access, mobile device management (MDM), and more.
One common method of authenticating with applications is SAML. This stands for the Security Assertion Markup Language. This is an open standard for authentication. And it allows an application to use a different authentication source to provide access to the app.
Although SAML works well for using web-based applications, it was not designed for mobile apps. So you may find that mobile apps are using a different process of authentication than using SAML.
The authentication flow with SAML is relatively straightforward. There are three devices involved in this SAML workflow. We’ll start with the one that you’re using. It’s your laptop. You’re probably in a browser. We refer to this as the client machine. We also have a device that we’d like to access. So we’ll need some type of authentication to access our resource server. And lastly, there is an authorization server that’s going to check our credentials and give us access to the resource server.
We start with our browser accessing a URL that’s located on this resource server. And that server is going to respond back with a signed and encrypted SAML request. This is sent directly back to you on the client. Inside of that request is a redirection to an authorization server.
The user is then presented with a login page and provides the authentication credentials. If everything matches, the authorization server will confirm the authentication, and it will create a SAML token and provide that token to the client. The client then presents that SAML token to the resource server. And the resource server now knows that the client must have authenticated properly and provides them with access to the app.
This is often integrated with a single sign-on process, or SSO. This prevents the process of providing a username and password every time you need to access a different resource on that network. We obviously don’t want this single sign-on to be something that is perpetual. So normally it will time out, usually in about 24 hours. And after that timer expires, we simply provide our username and password, and we get another 24 hours of access.
The authentication process that’s being used in your environment must support SSO for this to operate. And not all authentication protocols provide support for single sign-on. But if you are using single sign-on, it makes the process of using multiple resources much easier.
We often mention that a good security best practice is to prevent the use of an administrator account on all of your systems. But somebody on the network needs to be the administrator. In many organizations, there’s one or more people in the IT department that have administrator access. And in the past, it was very common to have that person have administrative access associated with their standard account. This means they were able to perform any type of function required by simply logging in with their normal user account.
This also means, of course, that the administrator’s account becomes a very valuable account to an attacker. If a third party somehow gains access to that user’s login, they would effectively have administrator access to the entire network. To prevent this from occurring, we can implement a just-in-time access. This means that the user getting administrative access would only have that access for a limited amount of time. This means that they can perform whatever task is required that needs elevated access, and then that access is revoked after a certain amount of time.
So in an environment where you’re using just-in-time access, even if the attacker gains access to the IT user’s account, they still would not have administrator rights. The way this usually works is, the person needing the administrator access would request that level of access from a central clearinghouse. And there’s usually additional authentication associated with that. The actual administrator’s account is stored in a password vault, and the vault is controlling who gets access to these particular credentials.
Instead of gaining access to the actual administrator account, this just-in-time access will create a new account with administrator access, but that account will be time-limited. The IT personnel will receive these ephemeral credentials. And eventually, those credentials will time out and no longer be available.
This means that the original administrator credentials are still in the password vault, and no one ever received those original credentials. All they received was a separate, time-sensitive set of credentials. And once those credentials time out, they are deleted and cannot be used again. If you need to provide access for your administration team to be able to perform their job but still protect your administrator accounts, you may want to look into just in time access.
We refer to the process of managing these Super User accounts as Privileged Access Management, or PAM. This is one that is associated with a Windows administrator account, a Linux root account, or any account that has additional rights and permissions. The process we described of just-in-time access is part of this privileged access management.
Not only does this centralize all of these privilege accounts and provide access to that in a secure way, we also have automation that can be associated with this. So now, not only do we have administrative accounts that are in a protected, secure vault, but we’re able to automate access to those and have extensive tracking and auditing. This is an important consideration, especially in environments where you want to be sure that those administrative accounts are tightly controlled.
Everyone in your organization has a mobile phone, a tablet, or perhaps even both. These are obviously powerful tools for the organization. But they can be a challenge to manage. In order to provide administration of all of these systems that are constantly in motion, you need to have Mobile Device Management, or MDM. Mobile device managers allow the IT department to manage all of these mobile devices from one central console.
This may be devices that are owned by the company. Or it may be devices that users have brought into the organization as their personal phone. We often refer to this as BYOD, or bring Your Own Device. Mobile device management allows you to centralize the management so that all of these devices can be managed from one central console. This certainly saves time for the administrator, and they’re able to see where all of these devices might be anywhere in the world.
The management part of the Mobile Device Manager allows the administrator to define what each device is able to do. They can set parameters for security. They can define what applications can run on this device. And they can set up a separate partition for the company’s data. This is especially important if you’re using BYOD, where some of the data on the device is personal data for that user, and other data on the device is owned by the company. If the user was to leave the organization, the MDM can delete the company’s data while leaving the user’s information in place.
And of course, security is an important consideration. And from the central console, you can have policies that require that everyone have a lock screen, they use a personal identification number on the lock screen, and you can set all of the detailed parameters for all of these security features.
We transfer sensitive information across our networks all the time, but it may be important to know where that sensitive information is going, and you may want to set policies that prevents that sensitive info from getting outside of your organization. One way that you can do that is through the use of Data Loss Prevention, or DLP. This allows an administrator to manage sensitive information such as Social Security numbers, credit card numbers, medical records, and any other type of personal data.
With DLP, we can identify the sensitive information and set policies on how this information should be transferred from one place to another. Most organizations will use multiple types of data loss prevention. There might be clients on the endpoints. There might also be DLP installed on the cloud-based systems, and you might have DLP functionality built into your email server or even your firewall. This means that information that is properly secured can be transferred or sent to the appropriate resource. And information that might be sent in the clear across the network is stopped before it gets into the hands of someone who should not be viewing it.
Our organizations used to have all of our applications located in our data center. And you would access them through an executable on your desktop. But these days, we have applications that are on our desktop, on our mobile devices, and they may be located anywhere in the world, not just in our private data center, but in cloud-based data centers that may be located on multiple cloud providers.
We also have more than just employees that are using these apps. We might have employees, customers, contractors, and other people accessing these applications at any particular time. The challenge is making sure that the person who needs access to the data gets exactly the type of data that’s required for their particular job function. We might have employees that need additional access to data, and there might be customers that should only be seeing the data associated with themselves.
To be able to manage all of this, we need Identity and Access Management, or IAM. This provides a set of life cycle management for the identity of people. Every person and every device is granted a digital identity, which now allows us to manage that device or that individual. Every individual and every device gets a digital identity. And we can provide access control to all of that so that each entity only gets access to the data that’s required. We can provide authentication and authorization, so we can set up strong login processes with multiple factors.
And we can prove that the person logging in is really the person they say they are. And in many organizations, we need to be able to track this entire process. It may be important to know when a particular customer accesses a particular resource. And we might want to perform standard auditing for our employees to make sure that they are only accessing the information necessary to perform their job. And in some organizations, there is a regulatory requirement to keep track of where all this data exists and how people are accessing that data using identity and access management.
Our IT administrators need to manage many different resources on the network. There are many different types of computing systems. We have servers, user accounts, file shares, printers, and many, many other resources. To be able to manage all of these very different systems, we need one single repository of information, a single database that contains all of these details. We often refer to this as directory services.
For example, if your organization is using Microsoft Windows, then they’re probably also using Active Directory, which has the standard set of directory services. Since all of these resources are in one single place, we can manage everything from one central console. For example, your IT team can manage the authentication that people use to gain access to these resources because all of the usernames and all of the passwords are stored securely in these directory services.
We can also centralize what type of access people have once they provide their login. So we can set up rights and permissions for certain folders, certain printers, and any other resource on the network. And if you’re part of a help desk, then you’re probably very familiar with directory services because, when somebody calls in and needs to reset their password, then we’ll need to access these directory services to make those modifications.