Are groups an appropriate model for authorization management?
A subject is a person, program, device, or other relevant entity which can authenticate to a system. Authentication is the process of confirming the identity of a subject.
Groups are collections of subjects and/or groups. As such, groups cannot authenticate, only the members which are subjects may authenticate.
Authorization is the process of deciding if a subject is allowed to have access to, or take action upon, a resource. Authorization presupposes that an act of authentication has taken place.
This implies that authorizations are not applied to groups, but can only be applied to subjects within a group. To many people this will feel like a counter-intuitive conclusion.
Often groups are constructed, so that one rule can confer the privileges to all members of the collection. This is often done because it is easy to understand. If you say, "The Red group can access this directory." then you can manage the access by controlling the membership of the Red group. This sounds implicitly efficient, but several issues arise from this model.
Re-examine the statement, "The Red group can access this directory." What information are we left with once this decision has been made? We have a group named "Red", and the current members of the "Red" group. Those two pieces of information are insufficient to determine what privileges are being granted to the members. The information is also insufficient to determine how the membership of the group was determined.
Within a small system, such as a local hard disk, it is relatively easy to examine the system and backtrack to determine exactly what privileges are being granted to the members of the "Red" group, via the group definition. However, when groups are centralized and accessible to all of the systems in a large enterprise, determining which privileges are granted by becoming a member of the "Red" group becomes an intractable problem. Note that a current common method of centralizing groups is by defining them, or exposing them, on an enterprise LDAP server.
Yet, many systems, and enterprises, have never evolved beyond the use of groups for authorization management. How do they cope?
Often enterprises will attempt to get a handle on their authorization management by imposing constraints, or more likely, conventions on the names of groups. For example a group named "bldg-1-access" may be used to enumerate people with access to building number one within an enterprise, while "bldg-2-access" is used to determine which employees can enter building number two. The convention might even be extended to indicate who can modify the access by creating groups named "bldg-1-access-admin" or "bldg-1-access-approval".
Of course, this tends to presupposes that everyone will understand the naming conventions and adhere to them. It also fails to take into account potential naming conflicts, inappropriate overloading of names, and the complexity of some systems. Perhaps most importantly such an approach takes us away from the fundamental problem of managing privileges and authorizations, and instead distracts us by forcing us to focus on the problems of group management instead. Does a group management system provide us with the ability to audit who has what privileges? Does a group management system know how the group definitions are being used? Instead a group management system gives you one more system to trust and you still haven't stored the real authorization rule anywhere but in the application code.
It is often attractive to put people into groups as the first step in creating authorizations, but too often once the groups are established the application is just coded to make use of these for authorization without ever creating the full authorization rule. This makes management of authorization rules as a service impossible. The real authorization question is who has what access to what resources. Managing groups reinforces the idea that authorizations are to control people.