Authorization Concepts, Assumptions and Issues

S Thorne 4/25/06 
            The hardest part of implementing an authorization service is getting the model right. In order to get a good model underlying concepts and assumptions need to be well understood. This paper goes into some of the thinking that was behind the OKI design.

Some of the topics are:

• Complicated isn't better
• Control the resources not the people
• Separating Management from Enforcement
• Authorizations are Business Rules
• The Three Part Model
• Groups
• Attributes
• Authorization Inheritance
• Implied Authorizations
• Negative Authorizations
• Authorization Authorizations 

Complicated isn't better

In order to have an effective authorization system, the users who have responsibility for determining the authorizations, will need to understand exactly what they mean. If the scheme is too complicated, users will generally add authorizations until the user can perform the functions. This results in granting too much authorization. If authorizations are so complicated that a specialist has to intervene, then this adds a potential for miscommunication. Complicated authorization rules can actually prevent the true goal of better authorization control from being achieved. Simple, well-understood authorizations are much easier to maintain and are more effective.

The best scheme for defining authorizations;

-         Uses terminology that will be understood by those who need to assign authorizations

-         Uses an appropriate level of detail in defining the functions that people can perform

o   Too much detail is confusing and hard to administer

o   Too little detail prevents authorizations from conforming to the way work is actually performed 

Control the Resources not the Users          

A common way of thinking is that the purpose of authorizations is to control what people do. Although this might be true, it is better to look at the problem from another perspective.  Authorization is meant to control access to resources and functions. It's the data and systems that are trying to be protected. Therefore, when designing schemes to distribute authorization control, it is best to think of in terms of distributing the responsibility and control of resources rather than people. An example will help illustrate the concept. Suppose SMITH works within the department of Biology, but needs access to resources within the department of Chemistry. Who is responsible for granting the authorization to SMITH? It is the authorizor for Chemistry, not the authorizor for Biology. The resources are controlled by the Chemistry department, so the Chemistry department determines who has access to their resources, regardless of where the consumers of those resources work. 

Separating Enforcement from Management

The application not the authorization service is responsible for interpreting and enforcing authorizations. The Authorization service can never be in a position to enforce authorizations, since the user facing application actually provides the functions. This means that authorization service itself doesn't need to interpret the meaning of the rules.
Often applications need to make use of underlying services. For example, a repository service will need to test and enforce the authorization rules themselves, since it can't always trust the application and needs to ensure it's own integrity. This means the authorization service is responsible only for maintaining the integrity of the authorization rules. Agreements about meaning and interpretation are only between the consumers of the authorization service.

Authorizations are really business rules

If authorizations are only specified in an implementation context, i.e. access to table yyy, screen zzz, or transaction xxx, then it is less likely that they can be shared by more than one application. For example, if you want to define who can see financial data in both the transactional system and a warehouse, you need to create an authorization rule, such as "can view financial information", rather than more specific rules which would only apply in one of the systems. It's up to each of the individual systems in this case to properly connect the general authorization rule with their internal authorization mechanism. 

The Three-Part Model

 
When most people talk about authorization they say things like; 
A person can do a function to an object

or

A person can do a function in some context or scope 
There are three parts to this concept. For example, one might say, "Sally can access Course material of Course 123", or "Tom is the grader for course 789." The three parts are found in these statements. If you haven't expressed all three parts of the statement, then the complete authorization rule has not been completely expressed. If only two parts are expressed, it is often because the third part is assumed. Often people cluster two parts of the basic authorization triplet in order to simplify authorization construction. However this apparent simplification creates problems, because one part of the authorization statement is not captured explicitly. It usually is a case of either overloading, or an out of band agreement.

In the overloading case; one relation is being used for two different purposes. For example, being in a certain group might mean both, that a student is in a course, and that they have access to course materials. Most of the time this works, but if you ever have someone who just needs access it means that you are faking the enrollment record to do this. There is usually an out of band agreement in this case also, since the rule that being in a group gives access to something isn't really being stored anywhere. Not storing the actual authorization rule makes it impossible to manage authorizations efficiently.

An authorization statement is only complete when all three parts are defined. Therefore maintaining all three in one relation is most efficient and has greater integrity. Although when reading this information sometimes the two-part structure is convenient, this can always be derived easily from the other structure. Let's look at some other common mechanisms as examples. 

Groups

            Often groups or lists of people are constructed, so that one authorization rule can govern the authorizations for the entire list of people. This is often done because it is easy to understand and often groups are needed for some other reason. 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.

You're putting two pieces of information together, when you really need three. This means you're only managing part of the authorization rule. Often when groups are used, information in their name is used to determine the authorization context. This is essentially an out of band agreement. There is often no system that defines the rule, it is just hard-coded in the application.

In this model the authorization control system ends up being the group management system.  Who can alter the membership of groups controls authorizations. This means these systems need to run securely. Many group management systems aren't designed as part of an authorization system and don't have audit logs etc. A group management system usually doesn't know what its' groups are being used for. You have one more system to trust and you still haven't stored the real authorization rule anywhere but in the application code.

Groups can be used for many things besides authorization, for example mail lists. This makes them attractive, but when the same group is being used for more than one purpose conflicts can arise. What happens when someone needs to be on the mailing list, but shouldn't have access? What the group can do is handled somewhere else. Sometimes a person gets added to a group to get on the mailing list, and inadvertently gains some authorization. When groups are used for more than one purpose, it is much more likely that the authorization system will then have to deal with negative authorizations or exceptions. Adding this requirement into an authorization service makes other efficiencies, such as inheritance or nesting more complicated or impossible.

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.  

Attributes

            Another common way of thinking about authorizations is with values assigned as attributes to the user. For example, suppose you can query a directory system, which can give you the values of attributes for users. These attributes might define the courses one was enrolled in. By looking at these attributes and the object being acted upon an application could make authorization decisions.

            There are a couple of potential problems with this approach. The attribute is typically serving two purposes. It is keeping track of enrollment and controlling authorization. Ask yourself in these cases if there ever could be a possibility of needing to be enrolled, but not being allowed access; or conversely needing access for someone who isn't enrolled. If these concepts aren't always the same then problems will arise.

            Another common variation of this is authorizations based on job title. At first it seems like a good idea, but often authorizations and job titles need to be controlled separately. You wouldn't want to inadvertently change authorization when someone in HR was modifying Job Titles and didn't understand the implications. It's better not to set up part of the authorization mechanism based on values controlled by another system, since it creates a situation where the person editing Job Titles effectively controls authorizations.

            In general it's a bad idea to base authorization decisions on another piece of data gathered for another purpose. If you really need to grant authorization for a person there is a tendency to alter the attribute to achieve this. This makes the data's original meaning invalid.

Another of the problems with this model is that the application must have knowledge of the meaning and interpretation of the specific attributes. Having to know this can prevent interoperability, since the application has to codify this knowledge. Running the same application in a different environment or institution might be difficult because of having different attribute names and values.

Also there is an implicit mapping of the attribute name or value, with the object being acted upon. Not explicitly managing this, makes inheritance behavior harder to implement, since changes to the inheritance hierarchy would have an effect on authorizations.

Inheritance

Imagine a hierarchy that organizes course content. At one level there might be nodes representing the broad subject or major. Under these there might be nodes representing individual courses, and then sections. Descending deeper in the hierarchy might be groupings of content; such as lessons, or types of resources, such as discussions, lectures, assignments, or even grades. At the lowest level of this hierarchy might be the nodes representing the individual resources themselves.

            This hierarchy represents the third part of the authorization; the scope or context. In O.K.I. this would be a Qualifier hierarchy. This hierarchy might be just a representation of the real objects. The nodes would have ids and names of the real objects, but are not actually the objects themselves.  This hierarchy would be used to support authorization inheritance.  An authorization assigned to a node at the top of the hierarch is inherited by all nodes below it.  Authorization queries could still be asked of the lower level nodes, even though there are not explicit authorizations assigned. These implicit authorizations have several advantages. There are much fewer authorization rules to maintain, but still supports fine grain authorizations. Also, if there are changes to the hierarchy; nodes are added or moved, it does not impact the authorizations, and no additional authorization maintenance needs to be performed. 

Implied Authorizations

            After having argued for the creation of explicit authorization rules; there are cases where this shouldn't be done. There are certain types of trivial authorization rules, such as a student can see their own grade that are probably best not represented as a specific authorization rule. In addition there are some very ephemeral objects that aren't going to be in existence long enough to justify having an explicit rule created. The authorization service might just be aware of their existence when the authorization test needed to occur.

Negative Authorizations

The ability to have negative authorizations always comes up in authorization discussions. It seems like a naturally good thing. However, this issue needs looking at carefully, because allowing for it makes other things harder to do. In general people are trying to manage authorizations as efficiently as possible. It makes sense to give a broad group some access, and negate the exception cases. However, in our view the need for negative authorizations indicates some flaw in the authorization model, usually due to overloading. If for example, the group only meant who had access, than this case would never arise. It means you're storing two different things in the same construct.

If you wan t to have inheritance in authorizations, then negation makes this more complicated. Negations usually need to take precedence in these situations. Therefore even if someone creates an authorization allowing you to do something, if there is another rule explicitly denying this then it overrules. A user of such a system is presented with a confusing senario. Even if they create the appropriate authorization rule, unless they get rid of any negation that might exist in the system, they won't really know the effect of their rule change. Stating the rules only in the positive makes it much easier to assess what authorization rules are really in effect. 

Authorization Authorization

            If you don't think through how you control access to the authorization management system, then you really haven't completely controlled authorizations. Knowing who can manage authorizations and what they have done is an important consideration when looking at the whole security picture.  

Conclusion

            Authorization is a complex topic and there are many valid approaches. The ideas presented here are meant to help identify issues that need to be thought out before an approach is taken. Often terms such as Roles, DRM, Groups and Access Lists get imbedded in the discussion, but some seemingly simplifying assumptions actually prevent a long lasting and flexible solution from being created. Authorization decisions are often based on other data, but often another abstraction is needed. If you don't explicitly store the authorization rules then you aren't going to be able to manage them. In many cases the solution is the layering of services so that all the needs can be preserved without dependencies that restrict service evolution. Strategies for service layering in this area will be presented in another paper.