...

• 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.

...

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.

...

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

...

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.

...

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.

...

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.