based on a modular authorization language for supporting cooperating distributed .... (since inherited rules will hold anyway but in case of conflicts). We assume ...
Modular Authorization Horst F. Wedde, Mario Lischka Informatik III University of Dortmund 44221 Dortmund, Germany {wedde,lischka}@ls3.cs.uni-dortmund.de
ABSTRACT There are three major drawbacks of a centralized security administration in distributed systems: It creates a bottleneck for request handling, it tends to enforce homogeneous security structures in heterogeneous user groups and organizations, and it is a weak point in terms of security attacks, reliability, and fault tolerance. In this paper we introduce a distributed authorization concept which is based on a modular authorization language for supporting cooperating distributed authorization teams. These teams are partially ordered into a hierarchy in that they inherit authorization rules from higher order teams but still exercise their autonomy by (dynamically) setting local rules that serve the special local needs in distributed organizations. Conflicts between between rules inherited from different higher ranking sources, or violations of higher order rules through local rules would be detected, on the logical level or through request evaluation, as contradictions or contradicting results, respectively. Conflict resolution mechanisms are presented, and examples are discussed extensively.
Categories and Subject Descriptors D.4.6 [Software]: Operating Systems—Security and Protection; K.6.5 [Computer Milieux]: Management of Computing and Information Systems—Security and Protection
General Terms authorization, role-based access control
Keywords modularity, composability, conflicts, violations
1.
INTRODUCTION
In a large organization a central administration is the bottleneck of the computer infrastructure, as the users have to sent all requests for changes to this agency and wait for the implementation through a small group of administrators. Apart from the fact that the organizational structure
SACMAT’01, May 3-4, 2001, Chantilly, Virginia, USA.
with its various departments, task forces, work groups must be represented in the system, the roles of their members have to be specified by the administration to model the handling of the data stored in the system. Numerous approaches have been presented to model all kind of access policies, but a central security operator was implemented in most of these projects. If the access policy is more complex, like in CSCW tasks, it is even ponderous and dangerous to give the central administration all knowledge necessary to implement the authorization policies completely. So, in summary, there are three major drawbacks of a centralized security administration in distributed systems: It creates a bottleneck for request handling, it tends to enforce homogeneous security structures in heterogeneous user groups and organizations, and it is a weak point in terms of security attacks, reliability, and fault tolerance. In this paper we introduce a distributed authorization concept which is based on a modular authorization language for supporting cooperating distributed authorization teams. These teams are partially ordered into a hierarchy in that they inherit authorization rules from higher order teams but still exercise their autonomy by (dynamically) setting local rules that serve the special local needs in distributed organizations. The implementation of these concepts are part of our Dragon Slayer project, a distributed file system which supports the needs of large heterogenous and decentralized organizations [10]. Here a modular authorization enables the administrative teams to specify the access control in a distributed environment like the Dragon Slayer system, through sets of rules. Authorization teams may be located in, or associated with, any department or work group of an organization. In order to represent their influence we define authorization spheres. We incrementally and adaptively model, in the Dragon Slayer file system, a very general framework of distributed authorization policies, through relations of roles, groups, and authorization spheres. While role patterns may help to model authorization mechanisms in an organizational group these patterns may also be autonomously refined, modified, or adapted by the local administrators in order to fulfill the special needs of the group. As a result of the (partial) autonomy of the authorization teams, conflicts between rules inherited from higher ranking groups may occur, e.g. the role “software developer” may be more restricted in one of the groups than in the other one. Such conflicts have to be detected, and conflict resolution will be a major topic of this paper. Another problem with distributed authorization stems from violations of inherited
rules through rules created under the local authorization privilege. Both conflicts and violations may be detected on the logical level or through a request evaluation. Since the authorization spheres are covering only few groups in the system only a small subset of rules would be evaluated once a user wants to access a file Under the Dragon Slayer system [9] all nodes which store a replica of a file (storage node), and the node where the user resides, collaborate to decide whether the access is granted or denied. The decentralized evaluation and the adaptive administration of our authorization rules are beyond the scope of this paper. They are subject of an upcoming publication.
1.1
Related Work
Role based access control has been widely discussed and many methods have been proposed to model the access properties. Lately our work has been taking advantage of [5, 4] and [1], in particular the ideas and techniques in the FAM language about logical checks of rules and the check of rule inconsistencies through request evaluation (test wise or online). This applies directly to violations as defined in the beginning of this section. We extended the FAM authorization language presented in [5, 4] to fulfill the necessities given by the distributed environment and to avoid a single system security officer. In [2] a flexible authorization mechanism is described but the well-known grantor strategy to pass rights is not very suitable for file systems. The ARGOS system [6] may impose global authorization rules to subordinate component systems in a federated data base system environment. In [3] an algebra for composing security policies is presented. This is done through combining rules that positively specify access rights to objects. There is no capability in their language to state, express, or evaluate conflicts. A major advantage of our approach, on the other hand, is that conflicts could be detected formally, and potential resolution mechanisms could be derived from the formal analysis.
company marketing evaluation
development network crypto VPN
Figure 1: hierarchy of the authorization spheres
The authorization sphere “company” may enforce that all objects labeled as “secret” may only be read by managers. The authorization sphere “development” may define additional roles like “developer” or “programmer”, which are unnecessary in the other department, or on the level of the authorization sphere “company”. In this sense, there is a hierarchy of the authorization spheres (see figure 1 and figure 2) while these groups could take care of their additional security needs independently. The access rights will be specified in our approach according to the task of each role in the project team. The members of each project team in figure 2 could be assigned to one of the five following roles of a group: A manager is the person mainly responsible for the project. A developer designs and specifies the components of the project. A programmer is coding the project according to the specification. A tester is checking the programs.
1.2
Organization of the paper
In the next section we design a scenario to further motivate our approach which is formally described in section 3. Our authorization language is defined in section 4, and in section 5 we describe how conflicts between various authorization policies are solved. Some examples are given in section 6. Conclusions are drawn in section 7, and an outlook on our future work is given.
A customer is a programmer or designer from other projects, who wants to use this work at an early stage. As shown in figure 3 these roles are partially ordered into a hierarchy which allows for a passing-on of access rights or denials.
company
2.
SCENARIO
In this section we briefly describe an application scenario suited to any software company, which is kept quite small, due to the page limitations. As shown in figure 1 the company has two departments “marketing” and “development”. The development department is organized in a number of project groups, which are working on different projects “network”, “crypto” and a subproject “VPN”. For a better placement of the products on the market a joint task-force “evaluation” has been founded with members from both departments. These departments, projects, and task-forces all have the potential capacity of authorization spheres in that each of them may be allowed to define its own access policies, to some extent.
marketing
web
evaluation
development
network
VPN Figure 2: group hierarchy
crypto
Manager
Developer
Tester
Prog.
Customer
Figure 3: role hierarchy
The various projects of the development department are linked. An individual person may be part of several projects but in different roles, like developer in project “network” and programmer in project “crypto”, as the latter urgently may at some time need more manpower. We may assume that this person should not access objects of the project “crypto” which are authorized for developers only. As each authorization sphere may define access policies of their own, conflicts may arise between those rules different in subordinate authorization spheres, e.g. in an authorization sphere like “evaluation” or “VPN” with two supervisory spheres. Strategies of solving these conflicts have to be specified that allow to derive a valid, i.e. conflict-free, set of access rules.
3.
MODULAR AUTHORIZATION
Considering the scenario in section 2, a manager has mostly the same function in every project team. The specific behavioral patterns and access rights for this role can therefore be partially determined by supervisory authorization rules from the authorization spheres. For the special needs in a subordinate project team, they would be adapted by adding authorization rules. In this section we will describe our view of groups and roles, and with this we will model principles for organizing the modular structure of the distributed authorization spheres in section 3.2.
3.1
Groups and Roles
As in other models that are based on role-based access control (RBAC) [8] “a role is a job function or job title within the organization with some associated semantics regarding the authority and responsibility conferred on a member of the role”. In our approach we additionally – and in contrast to [7]1 – define groups to model organizational units such as departments or project groups. We recognize that a user may play different roles in different groups, e.g. a “developer” of the group “network” may temporarily also be a “programmer” of the group “crypto”. If the access rights would only refer to a role, this user would be granted access to objects of the group “crypto” which are restricted to the role “developer” of this group. This may be undesirable. Thus the access rights, or limitations, for a particular person will be specified w.r.t. his or her membership 1
In [7] groups are set of users and a group can be assigned to roles. Thus the role is a assigned to all users which are member of the group.
in a group, project team etc. Consequently, every access right will be specified to apply to a pair (hrolei, hgroupi). For the purpose of formal specification we consider a group as a set of subjects and objects to pursue (possibly very complex) tasks. While objects are the data files needed for the task subjects are individuals who may manipulate the objects according to their roles in the group. The roles in our scenario are ordered hierarchically as shown in figure 3. Access rights will be formulated according to this hierarchy in such a way that typically access privileges of higher ranking roles would not be available in lower capacities while through their higher ranking, individuals may automatically have access rights associated with lower ranking roles. Also the holder of different roles in separate groups may have to be prevented from exercising privileges of a higher role in one group (e.g. “developer”) while acting in a lower role (e.g. “programmer”) in another group (as mentioned in the beginning of 3.1). Every time access to an object o is requested all authorization rules referring to o are checked.
3.2
Authorization Spheres
One new aspect of our modular authorization language is a decentralized definition of the access policies through local authorization teams. The access policy of a local authorization team, expressed through a set of rules, should be valid for a well–defined set of subordinate groups or their organizational functions. We call this the authorization sphere of an authorization team. An authorization team consists of all users who jointly may modify the set of rules of this authorization sphere. An authorization sphere is a special group, e.g. “marketing” in figure 2. However, while every group is within an authorization sphere we may consider, in figure 2, the group “web” not to have an independent authorization team. Authorization spheres do not overlap. In our model the authorization is partially done in a modular fashion, through the different authorization teams. At the same time we have an inheritance principle built into our model, which is based on hierarchical relationships between authorization spheres. In detail: 3.2.1 If a group has an authorization team which could define rules for accessing and manipulating objects then these rules are valid for the group, as well as for subordinate groups. 3.2.2 The autonomy of each authorization team is constrained by the rules defined by any authorization team in a supervisory group. In particular violations of superseding rules should be detected, and finally be removed (since inherited rules will hold anyway but in case of conflicts). We assume that the problem of violations in the context of our discussion (i.e. not for shaping the rule design process!) would occur during rule evaluation while handling authorization requests. This is beyond the scope of this paper. 3.2.3 In a group hierarchy the group of the highest order has an authorization team. 3.2.4 If two inheritance streams are merged into a subordinate authorization sphere this may lead to conflicts
in the corresponding components, in that access to a particular object may be granted according to one inherited rule set while denied according to the other. As an obvious assumption we have to assume that the inherited rules from the one and the other stream both apply to common subjects and objects, that where already addressed in supervisory authorization spheres. A conflict resolution is required that determines which of the conflicting rules applies. In order to model these conflict resolutions every group which inherits from two ore more superordinate authorization spheres must have an authorization team of its own. In section 5 we will show how enforcement, overruling, or extension of rules is expressed through our authorization language presented in the next section.
4.
FORMAL SPECIFICATION
In general, the authorization structure in a distributed system is typically heterogeneous, a result of the authorization sphere autonomy. Under such circumstances replication (like in the Dragon Slayer system) would be limited to an area where access to the replica would be subject to the same regulations on all of its nodes, i.e. to a subset of nodes within an authorization sphere. For the purpose of simplicity we assume through the following sections that the authorization structure is homogeneous within each authorization sphere in that all authorization rules are present at each node/group within the sphere. In this section we define our modular authorization language, a logical language with a fixed set of predicates which may be divided in two groups, access predicates and feature predicates. The former are used to model the access rights, while the latter describe the characteristic of subjects and objects which have to hold if the access should be granted. A is the set of all access predicates defined in section 4.4, while the set F contains all feature predicates specified in section 4.3. The evaluation of the access predicate is described in section 4.5. We first introduce all sets and their relations (4.1) and then the symbols used for the formal specification (4.2).
4.1
Sets and Relations
The following sets are defined in the system and used in this section to specify the modular authorization language. G is the set of all groups defined in the system. The groups are partially ordered into (G, as0 > g} = Ø
A single authorization sphere as may contain several groups g. In order to describe authorization rules that are to be valid for all groups an authorization sphere “system” is defined. “system” is the superseding organizational structure (“company” in figure 1). Since authorization spheres are interpreted as a subset of distinguished groups, they are partially ordered by the relation “ as ∧ {asx |asi > asx > as} = Ø
The relationship of roles is modeled through the following feature predicate. Definition 2 (role relation) The binary predicate rolein(r1 , r2 ) holds if r1 , r2 ∈ RT and r1 ∝ r2 according to the role hierarchy.
Definition 7 (type relation) The binary predicate typein(t1 , t2 ) holds if t1 , t2 ∈ T T and t1 ≥ t2 according to the type hierarchy. The file system may be structured through directories. In the Dragon Slayer system we may also structure files into parts for organizational reasons [10].
Every object as well as each assigned role are part of a group which may be related to other groups. Also recall from 3.1 that the objects needed by subject s (in a role r), are also considered as belonging to a group.
Definition 8 (object membership) The binary predicate
Definition 3 (group membership) The binary predicate
holds if object o1 ∈ OT contains o2 ∈ OT .
group(e, g) holds if entity e ∈ {ST ∪ OT } is a member of group g ∈ GT . In terms of definition 3 if x ∈ g 0 and g 0 < g; g, g 0 ∈ G the predicate group(x, g) will not hold. Definition 4 (group relation) The binary predicate groupin(g1 , g2 ) holds if g1 , g2 ∈ GT and g1 < g2 according to the group hierarchy or if g1 and g2 are identical. As authorization spheres are interpreted as groups G this predicate may also be used to describe a hierarchical relationship between two authorization spheres. Each object has a single owner who may be allowed to define special access rules. Definition 5 (ownership ) The binary predicate owner(u, o)
in(o1 , o2 )
Definition 9 (direct object membership) dirin(o1 , o2 ) holds, if o1 ∈ OT is parent of object o2 ∈ OT In the Dragon Slayer system even free attributes may be assigned to each object [11]. Definition 10 (object attributes) The ternary predicate attibute(o, al, av) holds if the attribute labeled al of object o contains the string av. A digital signature may be applied to an object in order to validate its contents. Definition 11 (object signature) The binary predicate signature(o, s) holds, if object o has a valid digital signature of subject s.
holds if user u ∈ U T owns object o ∈ OT The objects discussed here are typed (like in the Dragon Slayer file system). This information may be used to describe the kind of objects a rule should be applied to. Definition 6 (object types) The binary predicate type(o, t) holds if object o ∈ OT has the type t ∈ T T The objects in the Dragon Slayer file system are typed and these types may be related. This information may be used to describe the kind of objects a rule should be applied.
Previous access to objects may be used to model the workflow of an organization. Definition 12 (access history) The ternary predicate or the 4-ary predicate done(s, o, +a), done(s, o, +a, t) hold, if subject s has accessed object o by method a. t specifies the maximum time that this access may lie in the past. This covers the covers the feature predicates referring to the rules defined in 4.4. The set F contains all feature predicates defined in this section. We will illustrate the use of the predicates in section 6.
4.4
Access Predicates
In this section access predicates are defined, and the procedure for using them in access request evaluation is described.
Conflicting rules originating from different higher ranking authorization spheres will be handled according to the following rules.
The basic rule is used to enable or deny access under the condition stated in the body of the rule.
Definition 17 (grant rule) A grant rule for authorization sphere as has the form
Definition 13 (basic rule) A basic rule has the form cando(as, s, o, hsignia) ← L1 &..&Ln where as is the authorization sphere in which this rule is defined. If subject s wants to access the object o with method a all predicates Li ∈ F must (for given n and L1 , · · · , Ln ) hold; 0 ≤ i ≤ n. In this and all subsequent definitions, +a/ − a means that the access with method a is authorized/prohibited.
grant(as, s, o, hsignia) ← L1 &..&Ln access a to object o by subject s is handled according to hsigni if all predicates Li ∈ {F ∪ cando ∪ dercando ∪ do ∪ decide} (for given n and L1 , · · · , Ln ) hold; 1 ≤ i ≤ n.
4.5
Evaluation of access requests
The key features for granting or denying an access request are the grant rules. In detail: Assuming a request of subject s, for processing object o by using method a, arrives at the sites that hold copies of the object. The corresponding authorization sphere be as.
Derivation rules are used to link a file access to other access rights.
1. It will be checked for which grant rule in as, a is a matching method. If there is none the integrity of the rules is violated, and the response is “error”.
Definition 14 (derivation rule) A derivation rule has the form
2. For the resulting grant rules under further inspection, their right sides will be checked whether the particular triple (s, o, a) of the request is legal for each predicate Li in a configuration constituting a grant rule. (This involves an iterative process in evaluating rules according to definition 13 – 16.)
dercando(as, s, o, hsignia) ← L1 &..&Ln where as is the authorization sphere in which this rule is defined. The predicates Li ∈ {F ∪ cando}; 1 ≤ i ≤ n are either feature predicates or basic rules (for given n and L1 , · · · , Ln ).
3. The resulting Li will be evaluated. 4. If an expression of the form L1 &..&Ln has been identified where the Li are valid rules then the corresponding grant rule is valid.
The environments of our system may be highly dynamic. The predicate decide initiates the authorization sphere where the access request occurs to check with a user whether the access is granted or not. This user either owns o, or he has a role higher than the owner’s (see 4.1).
5. If one grant rule with expression L1 & . . . &Ln is evaluated to be valid and positive then the result “accept” is transmitted to s. If the evaluation result is negative then “deny” is transmitted.
Definition 15 (decision rule) A decision rule has the form
6. If different grant rules have conflicting results (a so far undetected conflict or violation) the response is “error”.
decide(as, sa , s, o, hsignia) ← L1 &..&Ln where the management process of authorization sphere as states that sa is the user who is queried whether or not the access a to object o is granted for subject s once all predicates Li ∈ {F ∪ cando ∪ dercando} (for given n and L1 , · · · , Ln ) hold; 1 ≤ i ≤ n. The following rule describes how, in a specified authorization sphere, new rules can be deducted based on the validity of specific access predicates. Definition 16 (deduction rule) A deduction rule within authorization sphere as has the form
Please note that the iteration mentioned in 2) halts. The scope of the access rules in definition 13 – 17 is growing yet the evaluation of a cando rule halts (only feature predicates), dercando contains only feature predicates or cando etc.
5.
CONFLICT RESOLUTION
In our approach, in general, all rules defined in an authorization sphere are passed on to subordinate spheres according to the hierarchy. If conflicting results are evaluated in an authorization sphere the reason might be:
do(as, s, o, hsignia) ← L1 &...&Ln
• The rules created in the lower authorization sphere are contradicting to one inherited from a higher one.
where for subject s to object o by access method a if all predicates Li ∈ {F ∪ cando ∪ dercando ∪ decide} (for given n and L1 , · · · , Ln ) hold; 1 ≤ i ≤ n.
• The rules inherited from more than one authorization sphere are contradicting.
The first phenomenon is called violation, and conventional approaches could be used to remove or avoid them (compare 3.2). In the second case a conflict of rules (3.2) has occurred.
Our principle for conflict handling is that all involved authorization teams in the affected spheres have to collaborate to resolve the problem. (Beyond the authorization sphere where the conflict occurs there are at least two immediate predecessor spheres involved (see 3.2).) As a result, from the inherited rules new and conflict–free rules will be created in appropriate ways. These resolutions for the affected authorization sphere will be inherited to all of its subordinate spheres. Conflict resolutions can be constructed in variety of different ways. In our scenario in section 2 “network” and “crypto” (figure 1) are two authorization spheres of different projects. In these two authorization spheres the access to an object of type “library” for subjects assigned to the role “customer”, may be handled divergently. Assume that the authorization sphere “network” has defined that a user assigned to the role “customer” may read an object of type “library” if the attribute “status” of the object has the value “stable”.
the assumption that each object in “VPN” the attribute “keywords” either has the value “net” or “crypt” but no combination, we may change the scope of the rules above by adding the line &attribute(o, keywords, net) to the rule defined by “network” and &attribute(o, keywords, crypt) to the rule define by “crypto”. Otherwise one may specify e.g. that the less restrictive rule of the contradicting rules will be discarded in the subordinate sphere. As general resolution strategies we mention briefly:
pessimistic Only the rules denying the access are used. optimistic Only the rules granting the access are used. general accepting The rules of the lower authorization sphere are always used, contradicting rules of of the higher authorization spheres are ignored. definition of exceptions The higher authorization spheres define exceptions for its rules.
cando(network,s, o, +r) ← type(o, library) &attribute(o, status, stable) &role(s, g, customer)&group(o, g) The group “crypto” wants to implement some stricter policies on their program libraries developed. Therefore a library has also to be signed by two developers of the group, before it may be accessed by the customer. cando(crypto, s, o, +r) ← type(o, library) &attribute(o, status, stable) &role(s, g, customer)&group(o, g) &signature(o, s1 ) &signature(o, s2 ) &role(s1 , g, developer) &role(s2 , g, developer) In our scenario (section 2 the group “VPN” is a subordinate authorization sphere of “network” and “crypto”, thus all rules defined in these authorization sphere are inherited. When a user with the role “customer” in group “VPN” wants to read an object of type “library” while its attribute “status” is “stable” but does not have any digital signature, the request is granted according to the rule inherited from the authorization sphere “network” but denied according to the rules inherited from “crypto”.
In order to resolve the conflicts the corresponding authorization teams might change the scopes of the contradicting rules in the following way. Assume that all objects have an attribute “keywords” which describes the content of the object. Assume further that the attribute “keywords” of all objects of the group “network” would contain “net” and the one of group “crypto” would contain “crypt”. Under
Modeling the optimistic or pessimistic solutions may be easy yet they may be inadequate for complex organizations. Another possible exception strategy is to change, in the immediate predecessor authorization sphere, the authorization rules causing the conflict in such a way that the conflict disappears. We give an example in 6.2
6.
EXAMPLES
In this section we present an excerpt of the rules for the scenario sketched in section 2.
6.1
Security Enforcement
In our scenario we want to specify for all authorization spheres that read access to secret information is limited to managers. Employees in lower positions may only read secret files if they own them. For this all objects in the sphere “company” are labeled by an attribute “secure” which may assume the values public, internal, confidential, secret, topsecret. To enforce the described policy the following rule is stated in the authorization sphere “company”: cando(company, s, o, −r) ← ¬role(s, g, manager) &group(o, g)&¬owner(s, o) &attrib(o, secure, secret) cando(company, s, o, +r) ← role(s, g, manager) &group(o, g) &attrib(o, secure, ≥ secret) cando(company, s, o, +r) ← owner(s, o) &attrib(o, secure, secret) do(company, s, o, −r) ← cando(comp, s, o, −r)& ¬cando(comp, s, o, +r) &attrib(o, secure, secret)
do(company, s, o, +r) ← ¬cando(comp, s, o, −r) &attrib(o, secure, secret) grant(company, s, o, −r) ← do(comp, s, o, −r)& ¬do(comp, s, o, +r) &attrib(o, secure, secret) grant(company, s, o, +r) ← do(comp, s, o, +r)& &attrib(o, secure, secret) Since these rules would be inherited by all subordinate authorization spheres (and conflicts with them could be easily avoided) they are in effect in each authorization sphere
6.2
Conflict Resolution for VPN
(compare section 5) Assume the group “VPN” develops a virtual private network and the members, except those that have been assigned the role “customer”, are also members in one of the higher authorization spheres. As the privacy of the communication channels which is to be established is assumed as critical as those for the “crypto” group, its access policies might be used, and and the objects constituting the privacy of the communication channels could be designed and implemented and therefore owned by members of “VPN” which are also members of “crypto”. For achieving this we proceed as follows: Instead of the contradicting rules defined in “network” and “crypto” (see section 5) the following rule is added to the authorization sphere “crypto” grant(crypto, s, o, +r) ← do(asp , s, o, +r) &owner(sp , o)&role(sp , r, ass ) &role(sp , r, g)&group(o, g) &type(o, library) The same rule, but for substituting “crypto” to “network”, will be added to the authorization sphere “network”.
7.
DISCUSSION AND CONCLUSION
In this paper we reported on a modularized distributed authorization approach which comprises the first stage of a large project for efficiently implementing, and administering, authorization in large-scale distributed systems. In order to overcome the shortcomings of a centralized security administration, regarding efficiency, flexibility, security, reliability, and fault tolerance we introduced distributed authorization teams which administer, or create, authorization rules for the groups/nodes within their authorization sphere. Since authorization in organizations is largely rolebased behavioral patterns and access rights for a role can be partially defined by higher ranking spheres, e.g. the sphere “company” in figure 1, and would be inherited by all subordinate spheres but for conflict cases. In this way a role like “manager” might be refined in a lower sphere, compared to the corresponding role in the higher spheres. Specific details of each role within an authorization sphere would be modeled into authorization rules under the autonomy of the authorization teams. (This is done in an unambiguous way, since authorization spheres do not overlap.) Beyond the advantages over a central authorization strategy mentioned above, authorization checks involve considerably smaller sets of rules in the distributed case, normally
just those administered by the corresponding authorization team. Also, due to distributing the authorization control, access requests in different authorization spheres will be evaluated concurrently. Thirdly, in centralized authorization schemes of simular role/object patterns suggest policies that differ in their restrictive rigidity while the (necessary) tendency under the centralized scheme is to establish the stricter regulation (worst case). In our distributed situation the weaker restriction could be imposed from the top level while the stricter rules are added, in a tailored fashion, by the corresponding authorization spheres (tailored case). A main technical contribution of this paper, within this novel distributed authorization concept, is the handling of conflicts. A variety of resolution mechanisms was presented. Conflicts in our understanding (see 3.2.4) are contradictions between access rules from a global point of view (namely between rules issued by independent authorization teams). Also violations are contradictions, namely with respect to superseding rules inherited from higher authorization spheres (see 3.2.2). Both of them are evolving as key phenomena in our dynamic interpretation of distributed rule generation in large organizations. (In contrast, the analysis problem (checking completeness of rules and lack of contradictions) has so far been treated as a static problem only.) Given a specific analysis method for a rule set A, the analysis in our decentralized approach is structured through the authorization spheres and the inheritance principle. The authorization teams need only check the rules that are under their administration. (One important issue here is that each subject belongs to an authorization sphere, and subjects belonging to authorization spheres on the same hierarchical level belong to exactly one of them.) So the check for completeness involves only a subset of authorization rules for each authorization team. Even if subjects migrate temporarily between groups or authorization spheres (on different levels, like VPN in section 2) each authorization team checks only for its ”own” subjects and their roles whether the access to objects is regulated in a conflict-free manner. In other words: The analysis of rule set A is structured and subdivided into smaller, local procedures, resulting in higher efficiency and lower complexity. While the last three paragraphs were concerned with analysis through decomposition of access control (involving authorization spheres on different hierarchical levels) we see an even more exciting perspective in modeling access control mechanisms by means of access rule composition. First, in our approach inheritance can be used as a guiding principle to stepwise refine access control, for shaping roles (e.g. ”manager”) in lower hierarchical levels. This is meant in the sense that within a group inherited rules are combined with rules specific for the group, resulting in access control patterns to be associated with the given role in that group. (Of course, violations (3.2.2) have to be avoided.) Second, the access rules for roles in a subordinate group (like VPN) can be modeled by inheritance from supervisory groups, by also adding group-specific rules. As long as conflicts between the inherited rules have been avoided, or would be resolved, we achieve a second form of rule compo-
sition. Third, if conflicts between authorization spheres on the same level do not occur the access rules for the group subjects are either in common (through inheritance) or independent of each other. Consequently a kind of algebraic rule composition for the groups on the same level could be composed from the independent rule sets as much as from the inherited rules. These three aspects of composability are currently also under study in our research project. So far, we have no implementation completed. However, such work is on the way. Right now we are working on principles for achieving a “complete” set of conflict resolution mechanisms, for a given application domain. (Whether or not rule conflicts arise depends to some extent on the scope of a role.) We are also pursuing strategies how to find a minimal amount of distribution of authorization rules within an authorization sphere such that access request evaluation needs to be done at a minimal number of system nodes only. This current and future research, application-dependent as it is, has started with, and makes use of a variety of, different application scenarios. This is subject to an upcoming publication.
8.
REFERENCES
[1] E. Bertino, F. Buccafurri, E. Ferrari, and P. Rullo. An authorization model and its formal semantics. In J.-H. Quisquater, Y. Deswarte, C. Meadows, and D. Gollmann, editors, ESORICS 98, 5th European Symposium on Research in Computer Security, volume 1485 of Lecture Notes in Computer Science, pages 127–142, Louvain-la-Neuve, Belgium, Sept. 16 – 18 1998. Springer Verlag. [2] E. Bertino, S. Jajodia, and P. Samarati. A flexible authorization mechanism for relational data management systems. ACM Transactions on Information Systems, 17(2):101–140, Apr 1999. [3] P. Bonatti, S. de Capitani di, and P. Samarati. A modular approach to composing access control policies. In Proceedings of the 7th ACM conference on Computer and communications security, pages 164 – 173, Athens Greece, nov 2000. ACM Press. [4] S. Jajodia, P. Samarati, and V. S. Subrahmanian. A logical language for expressing authorizations. In Proceedings of the IEEE Symp. on Research in Security and Privacy, pages 31–42, Oakland, CA, May 1997. IEEE Computer Society Press. [5] S. Jajodia, P. Samarati, V. S. Subrahmanian, and E. Bertino. A Unified Framework for Enforcing Multiple Access Control Policies Security. In Proceedings of the ACM SIGMOD International Conference on Management of Data, volume 26,2 of SIGMOD Record, pages 474–485, New York, May 13–15 1997. ACM Press. [6] D. Jonscher and K. R. Dittrich. Argos – A configurable access control system for interoperable environments. In D. L. Spooner, S. A. Demurjian, and
J. E. Dobson, editors, Database Security, IX: Status and Prospects, pages 43–60. Chapman & Hall, 1996. [7] S. Osborn and Y. Guo. Modeling users in role-based access control. In Proceedings of the 5th ACM Workshop on Role-Based Access Control (RBAC-00), pages 31–38, Berlin, Ger., July 26–27 2000. ACM Press. [8] R. Sandhu, D. Ferraiolo, and R. Kuhn. The NIST model for role-based access control: Towards a unified standard. In Proceedings of the 5th ACM Workshop on Role-Based Access Control (RBAC-00), pages 47–64, Berlin, Ger., July 26–27 2000. ACM Press. [9] H. F. Wedde, B. Korel, S. Chen, D. C. Daniels, S. Nagaraj, and B. Santhanam. Transparent Access to Large Files That Are Stored across Sites. In Readings in Distributed Computing Systems Theory. IEEE Computer Society Press, 1994. [10] H. F. Wedde and M. Lischka. New Dimensions in Distributed Journalism Through Dragon Slayer III. In Proc. of the 7th Euromicro Workshop on Parallel and Distributed Processing, Madeira, Portugal, Feb 1999. Euromicro, IEEE Computer Society Press. [11] H. F. Wedde and J.-O. Siepmann. A Universal Framework for Managing Metadata in the Distributed Dragon Slayer System. In Euromicro Workshop on Multimedia and Telecommunications. Euromicro, IEEE Computer Society Press, Sept. 2000.
