(DAP)
Ruan et al. proposed in Ruan, Varadharajan, and Zhang (2002) a logical approach to model delega- tion. They base their approach on extended logic programs (Gelfond & Lifschitz, 1991) so they allow explicit negation (denial) of authorization. Their language is based on the following concepts: • Subjects: These are the grantors and grant-
ees of authorizations. There is an special subject, the security administrator, denoted by #, which is the responsible for all authori-
zation in the system. Any authorization must be derived from one of the administrator authorizations.
• Objects: They are the target of authoriza- tions, that is, available system resources. • Access rights: The same object can be ac-
cessed in several ways. For example, a file can be accessed in read-only mode or in read-write.
• Authorization Type: DAP considers three authorization types: negative authorization (-), positive authorization (+) and delegatable
authorization (*). A negative authorization specifies the access that must be forbidden, while a positive authorization specifies the access that must be granted. Finally, a delegable authorization specifies the access that must be delegated as well as granted. DAP defines three partial orders<S, <O, <A to represent inheritance hierarchies of subjects, objects and access rights, respectively. We find examples of these partial orders in a classical UNIX system:
• Subjects are the system users. As the root
user is the administrator, any authorization issued to any user is also issued to the root. This translates into any-user <S root; • Files and folders are Objects, and the fact
that the files of a folder are accessible if the folder is accessible, is translated into folder
<O file-insider-folder;
• In a UNIX system there are three autho- rization types for files: read (r), write(w), execute(x) and the combination of them, an example order relation is the following
rw <Ar which represents that when granting
read-write (rw) access we are also granting
read-only (r) access.
In DAP, predicates consist of a set of ordinary predicates defined by users, and one built-in predicate symbol, grant, for delegatable autho-
0
Delegation Services: A Step Beyond Authorization
rization. The later is a 5-term predicate symbol with type S×O×T×A×Z, where the first argument
is the grantee, the second one is the object, the third is the authorization type, the fourth is the access right and, finally, the fifth argument is the grantor of this authorization. Intuitively,
grant(s,o,t,a,g) means s is granted by g the access right a on object o with authorization type t. grant
is called authorization predicate. There are two special predicates named cangrant and delegate, of type S×O×A and S×S×O×A, respectively, that are used to model delegation. cangrant(s,o,a) means subject s has the right to grant access a on object o to other subjects, while delegate(g,s,o,a) means subject g has granted to subject s access a
on object o with access type *.
In order to define a DAP rule the definition of the following concepts is necessary:
• Term: A parameter in predicates. It could be a variable or a constant, but not a func- tion.
• Atom: An atomic predicate. It is a con- struct of the form p(t1,...,tn) where each ti is a term.
• Literal: Either an atom p or the classical negation of an atom ¬p.
Then, a DAP consists of a finite set of rules of the form:
0 1 k k 1 k m 0
b ← , , ,b … b not b+ , ,… not b+ , ≥m ,
where each bi is a literal and not is the negation as failure symbol .
Once the administrator defines the DAP cor- responding to the system, it has to be transformed in order to be consistent with special predicates
cangrant and delegate. This is done by adding the following rules to the DAP and by doing some transformations on those rules in which the head (the leftmost element) is an authoriza- tion predicate. • d1. cangrant (#, o, a) ← • d2. Cangrant (s, o, a) ←grant (s, o,*, a, g) • d3. delegate (g, s, o, a) ←grant (s, o,*, a, g) • d4. delegate (s, s1, o, a) ←delegate (s, s2, o, a), delegate (s2, s1, o, a)
The previous rules are self-explanatory but we translate them to natural language anyway: d1
means that the security administrator # can issue authorization regarding any object and access right; d2 means that the grantee of a delegable au- thorization can issue new authorization regarding the granted object and access right; d3 means that the grantee of a delegable authorization has been delegated the respective access right on the respec- tive object; d4 is used to chain delegations.
In (Ruan, 2003), Ruan et al. extend their model with temporal capabilities by adding a new temporal parameter to predicates. They add two new elements to the system: time points and time intervals. Every authorization (grant predicate) is associated with a time interval and new rules have to be added to make the system consistent.
Once there is a consistent DAP, it would be possible to ask if a particular authorization predi- cate p is true trying to infer p from the rules of the DAP. As there are both positive and negative authorizations in a DAP, there could be conflicts among authorization, i.e. contradictory authoriza- tion predicates. DAP proposes several methods for solving conflicts:
• Using delegation relation: If the predicate
delegate (g, s, o, a) holds then all the autho- rization issued by g override the ones issued by s.
• Using grantee inheritance: When the grantors of two conflicting authorizations are the same, then we use the partial order on subjects to compare the grantees, if s<s s0, then the authorization with s0 as grantee will override the inherited one with s as grantee.
Delegation Services: A Step Beyond Authorization
• Using object inheritance: When both the grantor and grantees are the same we use the partial order in object to discard the authorization with the “lower” object. • Using access right inheritance: When all
grantors, grantees and objects are the same, we discard the authorization with the “lower” access right.
• Using time: We may also define an order relation between time intervals (inclusion is one easy example, but not the only one) and then, when all grantors, grantees, objects and access rights are the same, we discard the authorization with the “lower” interval.
RT Framework
Contrary to DAP, RT (Li, Mitchell, & Winsbor- ough, 2002)does not support negative statements, so RT does not have to worry about conflict reso- lution. It is based on a subset of Prolog, Datalog (Abiteboul & Hull, 1988; Ullman, 1988, 1989), which is a language of facts and rules. Datalog is a logic-based query language for the relational model that has been mainly used in the field of knowledge discovery but also in some other fields. One of the more attractive properties of DATA- LOG, regarding its tractability, is the absence of function-symbols as arguments in the predicates. This is the main reason for DATALOG having efficient procedures for answering queries.
Li et al. (2003) proposed logic programming as a way to model authorization and delegation relations. They use Roles for this purpose and they define a full general framework, RT for
role based trust management. It is composed of different languages, each of them with differ- ent characteristics. Roles can be interpreted as privileges or attributes. In DAP, resources are universal objects, known for all entities and are the same for each entity, but in RT, as it uses local names, each user could have his/her own roles (resources) or name them in a different way. The same role name could be used by two dif-
ferent users for different purposes. This is done by placing the name of the user before the role name, separated by a dot (e.g., A.Director is dif- ferent from B.Director). The only way to relate different roles is by means of credentials, which will be defined later on.
As in the previous proposal, the RT framework defines a partial order in roles, establishing how rights can be inherited. Partial orders are used to represent other concepts too. Let u, p, r denote users, rights and roles, respectively; then: • r1 ≥ r2, is read as r1dominates r2, and means
that r1 has all the rights r2 has. It can also be read as r2 contains r1. As an example, if we define two roles: Director and SubDirector; then clearly Director≥ SubDirector
• u≥ r assigns role r to user u. If Bob is the Director of the company, this can be ex- pressed with the predicate Bob≥ Director
• r≥ p assigns right p to role r. This is the only way to relate resources and access rights with roles. If SignContract represents the right of signing contracts, then Director≥ SignContract
RT defines several types of credentials, an analogous concept to DAP predicates. The basic credentials are:
1. A.R←D: This credential is issued by A
(like all the others) and it means that D is a member of A’s role R. In the attribute-based view, this credential can be read as D has the attribute A.R, or equivalently, A says that D has the attribute R.
2. A.R←B.R1: It means that the role A.R
includes all members the role B.R1. In the attribute-based view, this credential can be read as if B says that an entity has the attribute R1, then A says that it has the at- tribute R.
3. A.R←A.R1. R2: The expression on the right is called a linked role. It means that A.R
Delegation Services: A Step Beyond Authorization
contains B.R2 for all B in A.R1. The attribute- based reading of this credential is: if A says that an entity B has the attribute R1, and B says that an entity D has the attribute R2, then A says that D has the attribute R.
4. A R. ← . ∩ . ∩ ∩ .B R1 1 B R2 2 … B Rn n: This cre-
dential means that if an entity is a member of B1.R1, B2.R2, and Bk.Rk, then it is also a member of A.R. The attribute-based reading of this credential is A believes that anyone who has all the attributes B1.R1,..., Bk.Rk also has the attribute R.
The following is an example of the use of the previous rules. The first rule describes how a student gets a degree if and only if he/she passes the final exam and also completes the practical work. The second rule establishes that the practical work can be evaluated by the companies provided by the Subject. The third rule defines Bank1 as a valid company to evaluate the practical work. The last rule defines Bob as having passed the final
exam and also as having completed the practical work in Bank1.
Subject.pass ← Subject.passExam ∩ Subject. passPract
Subject.passPract ← Subject.company.pract Subject.company ← Bank1
Bank1.pract ← Bob
Subject.passExamn ← Bob
The previous are rules defined from RT0, which is the basic language of the RT framework, but there are more languages in RT. We will elaborate a little more on RT1, for a detailed description of the rest of the languages seeLi et al. (2002).
RT1 allows the use of constants and variables or parameters in the definition of roles and cre- dentials. In a credential, when we use the same variable in more than one role, we are linking the value of this variable for each role, so it has to be the same throughout the credential. When the same role has both a constant and a variable in
different credentials, in order to combine them, the variable should take the value of the constant. This language allows the previous example to be refined, adding marks to the subject. One way of adding grades to the previous example is by modifying the first and the last credential in the following way:
Subject.pass(x) ← Subject.passExam(x) ∩ Sub- ject.passPract
Subject.passExamn(B) ← Bob
In this way, the conclusion will be that Bob gets the degree subject with grade B.