Although logic programming offers a powerful mechanism to model authorization and delega- tion relationships and it is also very suitable for decision taking, it is not so easy to understand and has an obscure transcription; therefore there is a need for extensive training before being able to use it.
In order to close the gap between the user and the computer, there are graphical solutions that are thought to be less powerful but more expressive and more understandable. A graphical solution may be based on the use of directed graphs to model the authorization and delegation process. Basically, this maps each predicate to a directed arc in a graph. Arcs go from the issuer of the au- thorization or delegation statement to the subject who is authorized or granted privileges. There are as many different arcs as there are different authorization/delegation statements to consider. In this way, all the authorization and delegation relationships are represented in the same chart, making it easier for an inexperienced user to understand how the system is defined. Diagrams are always the first step in the process of software engineering and, similarly, they should also be in the field of security and authorization.
Delegation Services: A Step Beyond Authorization
Normally, an initial approach to the system is defined in a graphical way and then translated to a hard formalism in which authorization is decided. The problem of this approach is that the response of an authorization query can not be presented in a graphical way. If we use a powerful and simple graphical language to define our system, both queries and responses are expressed in a graphical way, allowing human interaction in the decision taking process.
We usually model authorization and delegation in the same chart but there could be scenarios in which only authorization or delegation is required. If we use a directed edge to represent each autho- rization or delegation statement, we get a graph in which all the paths come from the owner of the resource we are reasoning about. This graph looks like a tree (see Figure 7).
The root of the tree is the owner (administra- tor) of the resource. With such a tree it is possible to study the relationships among entities in the system in a graphical way.
Varadharajan and Ruan have proposed two solutions to represent authorization and delegation using directed graphs. In Ruan and Varadharajan (2003) they present a first approach to the problem. This approach considers three types of authoriza- tions: negative authorization, positive authoriza- tion and delegatable authorization, a cross arrow represents a negative authorization, a dashed arrow represents a positive authorization and a simple arrow represents a delegatable one.
In Ruan and Varadharajan (2004), the same au- thors proposed a new approach, weighted graphs. In that proposal, each authorization is associated with a weight given by the grantor, representing the degrees of certainty about the authorization grants. The weight is a nonnegative number, and a smaller number represents a higher certainty. When considering both negative and positive au- thorizations, conflicts result if the same subject is issued a negative and a positive authorization. In this case, we need to define a conflict resolution method that allows us to decide which of them has
to be considered. These authors follow the idea of predecessor-take-precedence. However, there are still some conflicts which they do not solve.
One example is when two contradictory paths exist, with the same weight; in this case their ap- proach can not provide any help. Their proposal has other limitations; in particular, owners of resources can not define more restrictive autho- rization policies. For some critical resources, the mere non existence of conflicts may not be enough. One possible solution is to require the existence of paths with at least a given weight for granting authorization.
An evolution of this solution which overcomes some of the limitations mentioned, is weighted trust graph (WTG) (Agudo, Lopez, & Montene- gro, 2005), that aims to generalize the previous approaches. In fact, WTG supports the previous proposal as a particular case.Additionally, WTG allows defining more complex policies. Even if in other solutions a delegation statement is usually
Delegation Services: A Step Beyond Authorization
issued together with an authorization statement, our solution can use both of them separately and independently, allowing us to introduce the notion of negative delegation.
WTG assigns a weight to each authorization that, together with the security level policy, al- lows many conflicts to be avoided. In the case that weights are the same, WTG follows a predecessor- take-precedence principle with some refinements; that is, a new conflict resolution method called
strict-predecessor-take-precedence.
This principle can also be used as a stand alone policy, where the owner of the resource establishes a hierarchy of subjects by assigning appropriate weights to their delegations, and any of the further delegations made for these subjects must preserve this hierarchy. For instance, if A
gets from S the higher priority in the hierarchy, all A’s delegation or authorization statements will take preference over all the others.
Then, in case contradictory paths exist, we compare them edge by edge until a difference is detected, and in this case, the path with the greatest weight in this edge will override the others.
If we had the following scenario in the pro- posal from Ruan et al. (see Figure 8), we would get no response when asking for an authorization decision, but applying the strict-predecessor-take-
precedence (changing greater for lower, because in the Ruan approach the greater the weight of the path is, the worse is the path) the path ACD would be chosen and therefore, D would not be authorized. This is because AC has a greater trust level than AB.
The main security policy is the mean policy. In this case, the weights of all paths connecting the two entities (the grantor and the grantee) are computed, and the mean of those values is calcu- lated. If the mean is included in a given interval then the user is authorized, and otherwise the authorization is denied. There are some important details that have to be taken into account in order to calculate a correct mean. These details are described in (Agudo et al., 2005). Apart from the
mean policy, there are other two simpler policies: the lower policy and the higher policy. In this case, the administrator or owner of the resource defines a lower bound in a way that an authorization is denied if the lower/higher weight within all the paths is lower than the defined bound. The last tool provided by WTG to control delegation, is the security level policy in which a lower bound is imposed for credentials (not paths as before) to be valid. In this case, edges or credentials with a weight lower than the given one, will not be taken into account when forming authorization paths. This policy permits discarding nonrelevant credentials.
All the previously defined authorization and delegation policies can be combined and owners of resources are in charge of defining their own custom combination of policies.
WTG defines a graphical representation for the four types of credentials supported:
a. Positive delegation statement: It means that the issuer trusts the subject about his/ her positive authorizations or delegations. Depending on the system, we may define this credential to be interpreted as a b or c
credential.
Figure 8. Example of unresolved scenario apply- ing Ruan’s policy
B
C
D
1
5
5
1
Delegation Services: A Step Beyond Authorization
b. Positive authorization statement: It means that the issuer authorizes the subject to ac- cess the resource.
c. Negative delegation statement: It means that the issuer trusts the subject about his/her negative authorizations or delegations. d. Negative authorization statement: It
means that the issuer denies access to the subject over the resource.
The weight is placed over the edges in the graph. The different edges that WTG support are represented in Figure 9.