- 1.1 Opinions, Products
- 1.2 Roadmap to the Book
- 1.3 Terminology
- 1.4 Notation
- 1.5 Cryptographically Protected Sessions
- 1.6 Active and Passive Attacks
- 1.7 Legal Issues
- 1.8 Some Network Basics
- 1.9 Names for Humans
- 1.10 Authentication and Authorization
- 1.11 Malware: Viruses, Worms, Trojan Horses
- 1.12 Security Gateway
- 1.13 Denial-of-Service (DoS) Attacks
- 1.14 NAT (Network Address Translation)
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.10 Authentication and Authorization
Authentication is when Alice proves to Bob that she is Alice. Authorization is having something decide what a requester is allowed to do at service Bob.
1.10.1 ACL (Access Control List)
Typically the way a server decides whether a user should have access to a resource is by first authenticating the user, and then consulting a database associated with the resource that indicates who is allowed to do what with that resource. For instance, the database associated with a file might say that Alice can read it, and George and Carol are allowed to read and write it. This database is often referred to as an ACL (access control list).
1.10.2 Central Administration/Capabilities
Another model of authorization is that instead of listing, with each resource, the set of authorized users and their rights (e.g., read, write, execute), service Bob might have a database that listed, for each user, everything she was allowed to do. If everything were a single application, then the ACL model and the central administration model would be basically the same, since in both cases there would be a database that listed all the authorized users and what rights each had. But in a world in which there are many resources, not all under control of the same organization, it would be difficult to have a central database listing what each user was allowed to do. This model would have scaling problems if there were many resources each user was allowed to access, especially if resources were created and deleted at a high rate. And if resources are under control of different organizations, there wouldn’t be a single organization trusted to manage the authorization information.
Some people worry that ACLs don’t scale well if there are many users allowed access to each resource. But the concept of groups helps the scaling issue.
1.10.3 Groups
Suppose there were a file that should be accessible to, say, any Dell employee. It would be tedious to type all the employee names into that file’s ACL. And for a set of employees such as “all Dell employees”, there would likely be many resources with the same set of authorized users. And it would take a lot of storage to have such huge ACLs on that many resources, and whenever anyone joined or left the company, all those ACLs would have to be modified.
The concept of a group was invented to make ACLs more scalable. It is possible to include a group name on an ACL, which means that any member of the group is allowed access to the resource. Then, group membership can be managed in one place, rather than needing to update ACLs at every resource when the membership changes.
Traditionally, a server that protected a resource with a group named on the ACL needed to know all the members of the group, but if there are many servers that store resources for that group, this would be inefficient and inconvenient. Also, that model would preclude more flexible group mechanisms; for example:
cross-organizational groups, where no one server is allowed to know all the members;
anonymous groups, where someone can prove membership in the group without having to divulge their identity.
Traditionally, groups were centrally administered, so it was easy to know all the groups to which a user belonged, and the user would not belong to many groups. But in many situations, it is useful for any user to be able to create a group (such as Alice’s friends, or students who have already turned in their exams in my course), and have anyone be able to name such a group on an ACL.
Scaling up this simple concept of users, groups, and ACLs to a distributed environment has not been solved in practice. This section describes various ways that it might be done and challenges with truly general approaches.
1.10.4 Cross-Organizational and Nested Groups
It would be desirable for an ACL to allow any Boolean combination of groups and individuals. For instance, the ACL might be the union of six named individuals and two named groups. If someone is one of the named individuals, or in one of the groups, the ACL would grant them permission. It would also be desirable to have the ACL be something like Group A and NOT group B, e.g., U.S. citizen and not a felon.
Likewise, it would be desirable for group membership to be any Boolean combination of groups and individuals, e.g., the members of Alliance-executives might be CompanyA-execs, CompanyB-execs, and John Smith. Each of the groups Alliance-executives, CompanyAexecs, and CompanyB-execs is likely to be managed by a different organization, and the membership is likely to be stored on different servers. How, then, can a server (Bob) that protects a resource that has the group Alliance-executives on the ACL know whether to allow Alice access? If she’s not explicitly listed on the ACL, she might be a member of one of the groups on the ACL. But Bob does not necessarily know all the members of the group. Let’s assume that the group name (Alliance-executives) can be looked up in a directory to find out information such as its network address and its public key. Or perhaps the group name would contain the DNS name of the server that manages that group, so the group name might be example.com/Alliance-executives.
Bob could periodically find every group on any ACL on any resource it protects, and attempt to collect the complete membership. This means looking up all the members of all subgroups, and subgroups of subgroups. This has scaling problems (the group memberships might be very large), performance problems (there might be a lot of traffic with servers querying group membership servers for membership lists), and cache staleness problems. How often would this be done? Once a day is a lot of traffic, but a day is a lot of time to elapse for Alice’s group membership to take effect, and for revocations to take effect.
When Alice requests access, Bob could then ask the on-line group server associated with the group whether Alice is a member of the group. This could also be a performance nightmare with many queries to the group server, especially in the case of unauthorized users creating a denial of service attack by requesting access to services. At the least, once Alice is discovered to either belong or not belong, Bob could cache this information. But again, if the cache is held for a long time, it means that membership can take a long time to take effect, and revocation can also take a long time to take effect.
When Alice requests access to a resource, Bob could reply, “You are not on the ACL, but here are a bunch of groups that are on the ACL, so if you could prove you are a member of one of those groups, you can access it.” Alice could then contact the relevant group servers and attempt to get certification of group membership. Then, she can reply to Bob with some sort of proof that she is a member of one of the groups on the ACL. Again, this could have a cache staleness problem, and a performance problem if many users (including unauthorized troublemakers) contact group servers asking for proof of group membership.
1.10.5 Roles
The term role is used in many different ways. Authorization based on roles is referred to as RBAC (role-based access control). In most usage today, a role is the same as what we described as a group. In some cases, Alice will need to log in as the role rather than as the individual. For example, she might log in as admin. However, many users might need to log in as admin, and for auditing purposes, it is important to know which user was invoking the admin role. Therefore, for auditing purposes, a user might be simultaneously logged in as the role (admin) and as the individual (Alice). In many environments, a role is given a name such as “admin”, and being able to invoke the admin role on your own machine should not authorize you to invoke the admin role on controlling a nuclear power plant. So, both groups and roles should have names that specify the domain, e.g., the DNS name of the service that manages the group or role membership.
Although a lot of systems implement roles as the same thing as groups, it is confusing to have two words that mean the same thing. We recommend that the difference between a group and a role is that a role needs to be consciously invoked by a user, often requiring additional authentication such as typing a different password. In contrast, we recommend that with a group, all members automatically have all rights of the group, without even needing to know which groups they are a member of. With roles, users may or may not be allowed to simultaneously act in multiple roles, and perhaps multiple users may or may not be allowed to simultaneously act in a particular role (like President of the United States). Again, we are discussing various ways things could work. Deployed systems make different choices. Some things people would like to see roles solve:
When a user is acting in a particular role, the application presents a different user interface. For instance, when a user is acting as manager, the expense reporting utility might present commands for approving expense reports, whereas when the user is acting as employee, the application might present commands for reporting expenses.
Having roles enables a user to be granted a subset of all the permissions they might have. If the user has to explicitly invoke the privileged role, and only keeps themselves authenticated as that role for as long as necessary, it is less likely that a typo will cause them to inadvertently do an undesirable privileged operation.
Allowing a user to be able to run with a subset of her rights (not invoking her most privileged role except when necessary) gives some protection from malicious code. While running untrusted code, the user should be careful to run in an unprivileged role.
Sometimes there are complex policies, such as that you are allowed to read either file A or file B but not both. Somehow, proponents of roles claim roles will solve this problem. This sort of policy is called a Chinese wall.