Understanding AAA Framework: Authentication, Authorization, and Accounting Explained

We're all very familiar with the login process. You put in your username, your password.

There might be some additional authentication factors. And if all of those are correct, you gain access to resources on that system.

This process begins with identification, where you claim to be a particular user on that system. The check between your username, your password,

and the other authentication factors is referred to as authentication. This proves that we really are who

we say we are because we knew the secret password, or we had some additional authentication factors that we could use to help prove that we are that person.

Now that we've identified who we are, we now need to determine what type of access we have. And that's done through authorization.

If we're part of the shipping and receiving department, then we should have access to systems that should only be available to shipping and receiving,

and we should not have access to information that might be in the finance department. And of course, all security systems

need to have a log of exactly what happened. So we need to know what time someone logged in, how much data may have been sent or received, and what time.

This person logged out. We refer to this entire system as the AAA framework. And this refers to Authentication, Authorization,

and Accounting. Let's have a look at a practical example of using AAA. We're going to use the example of logging in to a VPN server.

In this case, it would be a firewall or VPN concentrator in the middle. You're on one side of that concentrator,

and you need to use AAA to gain access to an internal file server. So we'll start with our client on the internet.

And we'll access the VPN concentrator, which prompts us for a login. So we're going to provide a username and password

and send that information over to the VPN concentrator. The concentrator itself doesn't have any information about usernames, passwords, authentication factors,

or anything else. And in most organizations, all of that information is stored on a central server.

And we refer to that as AAA server. This AAA server is going to receive the request from the VPN concentrator, asking

if the username, password, and other information that was provided matches some type of user in the database. And if the match is true, it sends back

information to the concentrator and says those credentials are approved. At that point, the concentrator knows that we really

are the person we claim to be, and it allows us access into the internal file server. As a security professional, you'll

be responsible for managing the security on hundreds or perhaps even thousands of separate systems. And in many cases, you'll never have physical access

or even be able to see where those systems might be because they may be located anywhere in the world. So the question now becomes, how can we

verify that a computer trying to connect to our network is a computer that's authorized to be on our network? This computer by itself obviously

can't type a password to prove who it might be. And in most cases, you probably wouldn't want to store a password on one of your systems

out in the field anyway. So how can you really confirm that that system is allowed to be on our internal network?

How do we provide that additional authentication? In many cases, we use a certificate that we put onto this device that is digitally signed.

And we check that authentication during the login process. This allows anyone needing to provide that verification with a way to confirm that that really

is a company-owned laptop. This could be on a VPN concentrator so that it can verify that the devices coming into the network

really are company devices. Or perhaps it's management software that can validate that end device that

may be either on our local network or anywhere in the world. The process for creating this certificate

is relatively straightforward. But the one thing that you must have in your environment is something called a Certificate Authority, or a CA.

This is a device or software that is responsible for managing all of the certificates in our environment.

On the CA itself, you would create a certificate just for that laptop. That certificate is now digitally signed

by the certificate authority so that, later on, we can verify that it really is an original certificate from our certificate authority.

Now we put that certificate on the laptop and, anytime we want to perform an authentication, we can use that certificate as an authentication factor

and verify that it really was digitally signed by the certificate authority. So as part of your security infrastructure,

you would have a certificate authority. That certificate authority itself has its own certificate that was signed by a root CA.

We also have our laptop in the field. And we have previously created a device certificate just for this machine.

And it has been signed by the CA. Once we know the CA certificate and we know the device certificate, we can then compare these two certificates.

And we can see that our device certificate was signed by the certificate authority that we trust in our security infrastructure.

Now that we've gone through the authentication process, how do we authorize that device to have access to resources within our network?

We would do that by using an authorization model. And there are many different authorization models to choose from.

We have a big list of these later on in the video series, in section 4.6. We would commonly authorize users and services

to have access to certain types of data and applications. The challenge here is, how do you create this relationship in a form that's able to easily scale for tens, hundreds,

or even thousands of users? In many environments, we accomplish this by taking the users and services and putting an authorization

model right in the middle before you access the data and the applications. These are commonly defined by roles, organizations,

attributes, and many other types of characteristics. Let's say that you had no authorization model at all. We would create a series of rights and permissions

where the user has rights to access the resource. The problem is that this doesn't scale very well. Let's take an example of somebody in the shipping

and receiving department. This is someone who needs access to a large number of systems, a lot of data.

Maybe there's tracking information, shipping labels, databases of customers. And we would create separate rights and permissions

so that any time this person logged in, we would need to give them rights to create a shipping label, track a shipment, view monthly shipment

reports, access customer data, and perhaps anything else they need for their day-to-day operations. Now, if this is the only person in shipping and receiving,

this is a relatively easy process. But what if you're part of a larger organization that has tens or hundreds of people in shipping and receiving?

You can see it would be difficult to take every single user account and manually set up rights and permissions for every single resource

that they need access to. In this case, there's only three resources. But imagine if there were tens or hundreds of resources.

You would need to set those up for the tens or hundreds of users. You can see now why this would be very difficult to scale.

To be able to scale, we would need to use an authorization model. Sometimes you'll hear this referred

to as an abstraction that allows us to separate the users from the information they're trying to access.

This greatly streamlines the process of administering these large number of users or large number of resources.

And we can support a very, very large infrastructure just with a very simple set of abstractions. Here's how this would work.

We'd have the same user in shipping and receiving, and we will add them to a group called Shipping and Receiving. We set this group up originally so that anybody

added to the Shipping and Receiving group would have access to create a shipping label, track a shipment, view monthly shipment reports,

have access to customer contact information, and anything else you would need in Shipping and receiving. Now let's add in our tens or hundreds of users.

Instead of manually mapping every single user to the individual authorizations they need, we just simply add all of the users to the Shipping

and Receiving group. With this one single addition, we can give tens or hundreds or thousands of users

access to the resources they might need, regardless of how many users there are and regardless of how many resources they need to access.