A Constraint Language for Adage * Draft of April 23, 1997. * William R. Bevier William D. Young Computational Logic, Inc. 1717 West 6th Street, Suite 290 Austin, Texas 78703-4776
[email protected],
[email protected]
1 Introduction Adage[SZ97a] is a system that supports the de nition and distributed enforcement of authorization policies. It is currently being designed at the Open Group Research Institute. In a companion paper[BY97], we describe a formal model of the authorization mechanisms of the Adage system. This paper elaborates several components of that formal model and describes a particular language for characterizing the constraints associated with authorization rules in an Adage authorization engine. This language is a superset of the one chosen for Adage, and is rich enough to permit a semantic de nition of Adage's authorization language. Section 2 reviews the basic notions of authorization in Adage and explains the purpose of our constraint language within the Adage context. In Section 3 we give a brief overview of our constraint language including several examples of its use. Sections 4 and 5 rigorously describe the syntax and semantics of our language. Section 6 explains how the constraints permitted in the current Adage design can be rephrased in our language. Finally, in Section 7 we explain the advantages of our approach and suggest some directions for additional research.
Draft.
2
2 Adage Authorization The basic action of the Adage authorization server is to grant a request by a principal to perform some action on some target. The decision to grant the request is based on a database of rules, as well as a history of previous actions. A rule is a generalization of an access control list, and describes a set of permitted actions. See [BY97] for the formal de nitions of these concepts. A rule in Adage is a generalization of an access control list. It speci es a set of actions that may be performed by a set of principals on a set of targets. Abstractly, a rule has two components: an applicability function and a policy function. The applicability and policy functions have identical signatures, but they are used in di erent ways. The applicability function is used to decide when a rule is pertinent to a given request. When applicable, a policy function is used to grant or deny a request. A rule database is a collection of rules. Type: Rule : hApplicability fn; Policy fn i
Function: Applicability fn : Request Time ?! Boolean Function: Policy fn : Request Time ?! Boolean Type: Database : Rule
The applicability and policy functions are evaluated in the context of a particular set of entities, a history of requests, and a rule database. They are de ned in terms of information associated with their arguments: the authorization spaces and trust levels of the participants of the request, a history of requests, and a time. The current authorization level of a principal is also a factor in the decision.1 We name the main interface to the authorization server Grant. Its purpose is to grant or deny a request. We specify Grant as a boolean function which is True if a request is granted, and is False otherwise. Grant takes as arguments a request and a time. The current context consisting of a set of entities, a history of requests and a rule database are implicit. A request hp; a; t i is granted if there exists an authorization region See [SZ97a] for a discussion of the way in which this model relates to the current Adage design. 1
3
Draft.
rgn within p's authorization space, and containing p's current region, such that the request is allowed if p assumes rgn as its region. The authorization check does not restrict p to act in its current region, but allows its region to expand if the request requires it and the authorization space allows it.2
Defn.
Grant ( hp; a; t i : Request; tm : Time) 9 rgn : L; p:ARegion rgn v p:ASpace ^ Applicable Rules Allow (hp; a; t i; tm) j p:ARegion = rgn
For an authorization to succeed, some rule must allow the request. In the case where con icts exist among applicable rules, authorization succeeds only if we nd a passing rule that is an exception to all stopping rules.3
Defn.
Applicable Rules Allow ( req : Request; tm : Time) Let A = Applicable Rules (req; tm);
9 rpass 2 A;
Rule Allows (rpass; req; tm) ^
8 r 2 A;
Con ict (rpass; r; req; tm) ) Is Exception (rpass; r; tm)
As a side e ect of granting a request, the authorization region of the principal may expand. We model the principal's new region as a function from the current state to a label. Function: New Region : Request Time ?! L If a request is granted, then the principal's new region is one at which the given request can be authorized, and it contains the principal's current An expression f (x) x = y means the value of expression f (x) in a state where x = y. So in the de nition of Grant, the authorization decision is made in a context in which the principal's region is equal to the candidate label rgn. It's important that all rules check the request at the same candidate region. 3 In the de nition of Applicable Rules Allow, Is Exception is intended to capture the notion that one rule is an exception to another for a given request in a given context. A speci cation for this concept is discussed in our companion paper[BY97]. 2
j
Draft.
4
region. If a request is not granted, then the new region is just the current region.4
Axiom.
Grant (hp; a; t i; tm)
)
Applicable Rules Allow (hp; a; t i; tm) j p:ARegion = New Region (hp; a; t i; tm) ^ p:ARegion New Region (hp; a; t i; tm)
Axiom. :Grant (hp; a; t i; tm) ) New Region (hp; a; t i; tm) = p:ARegion The current Adage design documents[SZ97a] describe a simple language for characterizing the PolicyFn component of rules. We have generalized and extended this language. We envision that it can be used both in describing both the Policy fn and Applicability fn components of rules. In the following section, we describe the syntax and semantics of our constraint language. In subsequent sections, we explain how to interpret current Adage rule constraint expression language in terms of our richer language.
3 Overview of Our Constraint Language Our language is designed to allow the speci cation of a variety of possible classes of conditions that might be imposed on the granting of a request hp; a; t i.5 These include at least the following classes of constraints.
Con dentiality and Integrity Constraints: relations that must hold between the security label of the requesting principal p and the label of the designated target t.
Trust Constraints: requirements that p satisfy certain \trust" related criteria, such as that p be local to the current cell.
In an ecient implementation, the authorization decision and a new region may be computed simultaneously. 5 In the parlance of the current Adage design documentation, these conditions express the relation component of an Adage rule. 4
Draft.
5
Role-based Constraints: relations relating to the set of roles a p may (or currently does) ll.
Membership Constraints: relations relating to the history of the system and to entities' membership in certain sets.
Time Constraints: speci cations of when a rule is in force. We also allow Boolean combinations of constraints and quanti cation of a constraint over the members of a set or sequence.
3.1 Some Examples
In Sections 4 and 5, we describe formally the syntax and semantics of our constraint language. However, to give a avor for the expressive power of the language, let us consider some simple examples drawn from the security literature.
The Bell-LaPadula Model Policies based on this model deal with the
con dentiality level of subjects (principals) and objects (targets) according to the e ects of particular actions. Subjects may read only objects which are at the same or lower" security level and write only objects at the same or higher security levels. In our simpli ed version of the Bell-LaPadula model, we might have the following constraints: Simple Security: Any \read" action must satisfy the constraint: CLEVEL (THIS-P) >= CLEVEL (THIS-T).
The *-Property: Any \write" action must satisfy the constraint: CLEVEL (THIS-P) = ILEVEL (THIS-T).
The Chinese Wall Policy The Chinese Wall policy is intended to capture
constraints imposed in some commercial settings. As an example, suppose we have a consultant who can work for any of several competitors. Ethically, he may work for any of them, but only one at any given time, and he must not transfer information from one to another. Given a number of datasets (targets) within a \con ict of interest set" S, he may access one of the datasets only if he has not touched any of the others. We might impose the following constraint on any action on any of the datasets in S. FORALL x in S, (x != THIS-T) -> (NOT x IN TGTS (RESTRICT-P (THIS-P, H))).
If hp; a; t i is the current request, we read this constraint as follows. No member of S other than t is among the targets mentioned in the restriction of the current history to those transactions for which p was the principal. I.e., p has not previously accessed any member of S other than t.
Separation of Duty Separation of Duty is a class of constraints intended
to ensure checks and balances within an organization. There are various types of separation of duty[FCK95], several of which can be handled in Adage[SZ97b]. An n-person rule assures that at least n distinct parties take some action. For instance, a check must be signed by two di erent individuals in the role SIGNERS, before it can be released. This is phrased in our language as the following constraint on the \check release" action.
Draft.
7
AT-LEAST 2 x IN PRINS (SIGNERS), x IN PRINS (RESTRICT-T (THIS-T, RESTRICT-A ("sign-check", H))).
That is, assume hp; a; t i is the current request and consider all past transactions in which the action \sign-check" occurred on target t. At least two (distinct) of them involve principals from the role SIGNERS. Exclusion rules insure that a single individual may not inappropriately assume multiple roles. For example, a nancial report may require signatures from persons operating both in the roles of ACCOUNTANT and AUDITOR. However, even if there are individuals permitted to operate in both roles, we disallow the same person serving in both roles for a single report. This would yield the following constraint on the \report release" action. EXISTS x in PRINS (ACCOUNTANT), EXISTS y in PRINS (AUDITOR), (x != y) AND {x, y} SUBSET PRINS (RESTRICT-T (THIS-T, RESTRICT-A ("sign-report", H))).
This is similar to the previous example. It says that there are distinct principals from roles ACCOUNTANT and AUDITOR who have taken action \sign-report" on the current target (according to the current history). We believe that the other forms of exclusion rules described in [FCK95, SZ97b] can be captured in our language as well.
Trust Constraints There are a variety of constraints we might wish to
impose in a context in which entities and information are introduced from external sources (cells). For example, associated with each principal is a \chain" which is a sequence of cells via which that principal came to be known in the current cell. We might trust a principal to perform certain actions only if each element of that chain has a trust level exceeding some threshhold, say 3.6 We can express this in our constraint language as follows: We have not committed to any particular representation for trust levels. We just choose an integer value here for convenience. 6
Draft.
8
FORALL c in CHAIN (THIS-P), TLEVEL (c) > 3.
Alternatively, we may wish to allow an action only if the requesting principal is local. We express this as follows: ORIGIN (THIS-P) == HERE.
Time Constraints A time component is included in Adage rules to indicate when a particular rule is in force. If there is no time constraint, the rule is assumed always to be in force. We have a simple set of constructs that allow us to specify dates, times and ranges of times. For example, a rule that applies only when a business is closed might have a time constraint: (WEEKDAYS BEFORE 08:00:00) OR (WEEKDAYS AFTER 17:00:00) OR WEEKENDS
This is interpreted to mean that the constraint is in force (evaluates to true) if the current time satis es the constraint. Presumably, time constraints will be used in the de ning the applicability function of a rule rather than its policy function, as described in Section 2. To anyone familiar with the Adage constraint language two things will be obvious. First, most of our examples can be handled by the current Adage mechanisms. Indeed, several of these examples are drawn from the Adage manual. However, the Adage mechanism comprises a collection of cliches designed for speci c types of constraints. We believe that our language is richer, more expressive, and more easily extensible. The inclusion, for instance, of quanti cation allows us to state interesting constraints that, as far as we know, cannot be stated within the current Adage constraint language. Second, our language is a bit verbose. An early task would be to identify common cliches such as nested history restrictions and devise a more compact notation, either as an extensions to the language or as abbreviations.
4 The Syntax of our Language The syntax of our constraint language is de ned by the grammar given below. The \start" symbol is term, which can be any of three types: a boolean combination of other terms, a quanti ed term, or a \constraint" term.
Draft.
9
term ::= bterm | qterm | cterm
4.1 Boolean Combination of Terms
We currently de ne only a representative group of boolean operators. Others could be added quite easily. bterm ::= NOT term | term AND term | term OR term | term XOR term | term -> term | term IMPLIES term
4.2 Quanti ed Terms
Quanti cation over terms facilitates modeling least privilege and separation of duty concerns. In addition to the typical universal and existential quanti ers, we also allow specifying that \at most n" or \at least n" members of a set have some property. qterm ::= quantifier binding term quantifier ::= FORALL | EXISTS | AT-LEAST nat | AT-MOST nat binding ::= var IN set | var OVER seq
4.3 Constraint Terms
Much of the expressive richness of our language comes from the collection of \constraint" terms. These express constraints on the con dentiality and integrity levels of entities, trust relations on principals according to their originating cell, relations based on the roles memberships of entities, and appearance of entities in certain histories or sets. cterm ::= comparison | clevelrel | ilevelrel | trustrel | rolerel | memberrel | timerel
Components of the Model The basic components of our model are the
principals, actions, targets, roles, and cells. We can refer to any of these by name or by certain stylized cliches.
10
Draft.
principal principalname action actionname target targetname entity rolename cell cellname
::= ::= ::= ::= ::= ::= ::= ::= ::= ::=
THIS-P | principalname var THIS-A | actionname var THIS-T | targetname var principal | action | target var HERE | ORIGIN (principal) | cellname var
Comparisons We allow equality comparisons of entities, roles, or cells. In addition, we have other relational operator for quantities and sets. eqop entitycomp rolecomp cellcomp comparison relop srel
::= ::= ::= ::= ::=
!= | == entity eqop entity rolename eqop rolename cell eqop cell entitycomp | rolecomp | cellcomp
::= eqop | > | >= | < | 8 Compute (val1 ; val2) = > if val1 2 R ^ val2 2 R; < val1 > val2 ; if ilevel (val1) ^ ilevel (val2 ); > val1 >i val2; : val1 >c val2 ; if clevel (val1) ^ clevel (val2 ). The other relational operators are de ned similarly. The following function applies an operator to its evaluated arguments.
De nition 5.15
Relop 8 Compute (op; val1; val2 ) = > < > Compute (val1; val2 ); < Compute (val1; val2 ); > .. : .
if op is >; if op is < Relop Compute (op; CLevel Interp(term0; env); > : CLevel Interp(term00 ; env))
if term = term0 op term00 ^ Relop (op); ^ CLevel (term0 ).
21
Draft.
De nition 5.18
CLevel Interp (term; env) = ( clevel (Entity Interp (e; env)),
if term = CLEVEL (e) ^ Entity (e).
Integrity levels are handled analogously.
De nition 5.19
ILevel Rel Interp (term; env) = 8 > < Relop Compute (op; ILevel Interp(term0; env); > : ILevel Interp(term00; env))
if term = term0 op term00 ^ Relop (op); ^ ILevel (term0).
De nition 5.20
ILevel Interp (term; env) = ( ilevel (Entity Interp (e; env));
if term = ILEVEL (e); ^ Entity (e).
Trust Relationships trustrel tlevel chainlen seq
::= ::= ::= ::=
tlevel relop tlevel | chainlen relop chainlen TLEVEL (cell) LEN (seq) | nat CHAIN (principal) | AFTER (cell, seq) | BEFORE (cell, seq)
Trust relationship are also expressed by cterms. Our semantics assumes that each principal is either local (de ned in the current cell) or the citizen of another cell. A non-local principal will have an associated chain{a sequence of cellnames representing the chain of introductions through which the principal came to be known in the local cell. The local cell assigns trust levels to other cells and may constrain the actions of a non-local principal according to the trust level of its origin, or according to properties of the cells in its introduction chain. We currently support only relational comparisons on trust levels and reference to the length of a principal's introduction chain.
22
Draft.
De nition 5.21
Trust Rel Interp (term; env) = 8 > Relop Compute > > (op; TLevel Interp (term0; env); > > > < TLevel Interp (term00; env)); > > Relop Compute > > (op; Chainlen Interp (term0; env); > > : Chainlen Interp (term00; env));
if term = term0 op term00 ^ tlevel (term0) ^ tlevel (term00); if term = term0 op term00 ^ Chainlen (term0); ^ Chainlen (term00).
De nition 5.22
TLevel Interp (term; env) = n tlevel (Cell Interp (cellname); env);
if term = TLEVEL (cellname):
De nition 5.23
Chainlen Interp (term; env) = ( jSeq Interp (term0; env)j, val (n);
if term = LEN(term0); if term = n ^ val (n) 2 N .
Sequences arise in trust relationship when we refer to the introduction chain of a principal. Our only current means of extracting a subsequence is by identifying a cellname, and extracting the subsequence up to that element or following that element. We also allow quanti cation over a sequence.
De nition 5.24
Seq Interp (term; env) = 8 chain (Principal Interp (term; env); env), if term = CHAIN (p) > > > ^ Principal (p; env); > < after (Cell Interp (c; env); if term = AFTER (c; seq) > Seq Interp ( seq ; env )) , ^ cellname (c; env); > > before (Cell Interp (c; env); if term = BEFORE (c; seq) > : Seq Interp(seq; env)), ^ cellname (c; env).
23
Draft.
Role-based Constraints rolerel ::= rolename IN roleset | roleset srel roleset roleset ::= ROLES (entity) | FROLES (principal) roleentityset ::= PRINS (rolename) | ACTS (rolename) | TGTS (rolename)
Recall that a role is a hteam; actionset; targetset i triple. The semantic function roles (e) for entity e, gives the roles in which e may participate. For principals, there is the additional notion of a oating label which de nes the roles in which it is currently participating. The semantic function froles (p) returns this set for principal p. Our constraint language allows us to make reference to the roles of any entity, and to the current roles of any principal. In addition, we can extract the various component sets from a role.
De nition 5.25
Role 8 Rel Interp (term; env) 0= Principal Interp (term ; env) > > > 2 Role Set Interp; (term00 ; env), > < > Srel Compute > > (op; Role Set Interp; (term0; env); > : Role Set Interp; (term00; env)).
if term = term0 IN term00; if term = term0 op term00 ^ Srel (op);
De nition 5.26
Role 8 Set Interp (term; env) = > > roles (Entity Interp (e; env); env), < > > : froles (Principal Interp (p; env); env);
De nition 5.27
Role 8 Entity Set Interp (term; env) = prins (r; env), > > > > < acts (r; env), > > > tgts (r; env), > :
if term = ROLES (e) ^ Entity (e; env); if term = FROLES (p) ^ Principal (p; env). if term = PRINS (r) ^ rolename (r; env); if term = ACTS (r) ^ rolename (r; env); if term = TGTS (r) ^ rolename (r; env).
24
Draft.
Membership Constraints hterm
::= EMPTY | H | RESTRICT-P (principalset, hterm) | RESTRICT-A (actionset, hterm) | RESTRICT-T (targetset, hterm)
principalset
::= principal | { principal* } | PRINS (rolename) | PRINS (hterm) | ALL | NONE ::= action | { action* } | ACTS (rolename) | ACTS (hterm) | ALL | NONE ::= target | { target* } | TGTS (rolename) | TGTS (hterm) | ALL | NONE
actionset targetset
set
::= principalset | actionset | targetset | roleset
memberrel
::= principal IN principalset | action IN actionset | target IN targetset | principalset srel principalset | actionset srel actionset | targetset srel targetset
We support two distinct types membership constraints: membership in a role or set of roles, and occurrence in a history. To state constraints based on the history of actions taken in the system, it is necessary to be able to manipulate histories. Recall that a request is a triple hp; a; t i; a history is a sequence of requests that have been granted. In our constraint language, H denotes the current history; EMPTY denotes the empty history. We de ne three \restriction" functions, to allow us to project out the subsequence of requests involving given sets of principals, actions, or targets from a given history. Using these restriction functions, we can compute, for example, the list of all requests involving a given target or the list of all requests involving a speci c principal and target pair. The use of sets ALL and NONE makes specifying such computations straightforward.
De nition 5.28
Restrict P (pset; env) =
25
Draft.
8 > < fg, h p; a; t i Restrict P (pset; h0), > : Restrict P (pset; h0),
if pset = fg; if h = hp; a; t i h0 ^ p 2 pset; if h = hp; a; t i h0 ^ p 2= pset.
Restrict A and Restrict T are de ned analogously. The following function de nes our history manipulation sublanguage.
De nition 5.29
HTerm Interp (term; env) = 8 fg, if term = EMPTY; > > > if term = H; current history (env), > > > > > if term = RESTRICT-P (set; hterm); Restrict P > > (Principal Set Interp (set; env); > > HTerm Interp (term0 ; env)), > > < > Restrict A if term = RESTRICT-A (set; hterm); > > ( Action Set Interp ( set ; env ) ; > > > HTerm Interp (term0 ; env)), > > > > Restrict T if term = RESTRICT-T (set; hterm). > > > Target Set Interp (set; env); > : (HTerm Interp (term0 ; env)),
We can also form sets of entities by extracting the components of a role or by projecting out the principals, actions, or targets of a history. In addition we can refer to the entire set of known principals, actions or targets. We can treat a single entity as a set, or generate a set explicitly by listing its members.
De nition 5.30
Principal Set Interp (term; env) =
26
Draft.
8 > > > > > > > > > > > > > < > > > > > > > > > > > > > :
fPrincipal Interp (term; env)g,
if Principal (term; env);
fPrincipal Interp (term1 ; env);
if Principal (term1 ; env)
:::
Principal Interp (termk ; env)g,
:::
^ Principal (termk ; env);
fg,
if term = NONE; if term = ALL;
prins (env (r); env),
if term = PRINS (r) ^ rolename (r; env); if term = PRINS (term0 ) ^ HTerm (term0).
All Principals (env),
Collect Prins (HTerm Interp (term0; env); env),
De nition 5.31
Action Set Interp (term; env) = 8 fAction Interp (term; env)g, > > > > > fAction Interp (term1 ; env); > > > ::: > > Action Interp (termk ; env)g, > > > < > fg, All Actions (env), > > > > > acts (env (r); env), > > > > > Collect Acts > : (HTerm Interp (term0; env); env),
De nition 5.32
Target Set Interp (term; env) =
if Action (term; env); if Action (term1 ; env)
:::
^ Action (termk ; env); if term = NONE; if term = ALL; if term = ACTS (r) ^ rolename (r; env); if term = ACTS (term0 ) ^ HTerm (term0).
27
Draft.
8 > > > > > > > > > > > > > < > > > > > > > > > > > > > :
fTarget Interp (term; env)g,
if Target (term; env);
fTarget Interp (term1; env);
if Target (term1 ; env)
:::
Target Interp (termk ; env)g,
:::
^ Target (termk ; env);
fg,
if term = NONE; if term = ALL;
tgts (env (r); env),
if term = TGTS (r) ^ rolename (r; env); if term = TGTS (term0 ) ^ HTerm (term0).
All Targets (env),
Collect Tgts (HTerm Interp (term0; env); env),
The syntactic category of member relationships collects together the various constraints that claim membership of an entity in a set or sequence.
De nition 5.33
Member Rel Interp (term; env) = 8 > Principal Interp (p; env) > > 2 Principal Set Interp (set; env), > > > > Action Interp (a; env) > > > 2 Action Set Interp (set; env), > < > Target Interp (t; env) > > 2 Target Set Interp (set; env), > > > > > Srel Compute > > (op; Entity Set Interp (term0; env); > > : Entity Set Interp (term00 ; env).
if term = p IN set ^ Principal (p; env); if term = a IN set ^ Action (a; env); if term = t IN set ^ Target (t; env); if term = term0 op term00 ^ Srel (op);
Finally, we have expressions for describing the sets used in member relationships and in quanti ed expressions.
28
Draft.
De nition 5.34
Entity Set Interp (term; env) = 8 > < Principal Set Interp (term; env), Action Set Interp (term; env), > : Target Set Interp (term; env),
if Principal Set (term; env); if Action Set (term; env); if Target Set (term; env).
De nition 5.35
Set ( Interp (term; env) = Role Set Interp (term; env), Entity Set Interp (term; env),
if Role Set (term; env); if Entity Set (term; env).
Time Constraints timeofday date timedate timept dayofweek timerange time
::= ::= ::= ::= ::= ::=
hh:nn:ss mm:dd:yyyy timeofday date timeofday | date | timedate SUNDAY | ... | SATURDAY | WEEKDAY | WEEKEND date | dayofweek | BEFORE timept | AFTER timept | FROM timept TO timept ::= timerange | timerange AND timerange | timerange OR timerange | timerange EXCEPT timerange
Time constraints specify when a rule is in force. Providing a completely formal semantics is possible but rather complicated since it involves determining such things as on which day of the week a particular date falls. Therefore, we give only an informal semantics for this portion of our constraint language. Assume a context in which we measure time at the granularity of seconds. Then a canonical time speci cation gives a date and time to the second. From a canonical time, we assume that functions are available to extract the second, minute, hour, day, month, year, and day of week. If we specify a time with any of these omitted, it denotes a set of times where all possible values are lled in for the missing item. For example, the term AFTER 4PM means ft : 16:00:00 < Time (t) < 24:00:00g and the term SATURDAY refers to ft : day of week (t) = Saturdayg. A time speci cation describes a set of times. The time constraint described by term is assumed satis ed if current time 2 Time Rel Interp (term; env). Clearly there are some useful time speci cations that cannot be conveniently
29
Draft.
captured in this simple language: eg. \any Friday the 13th" and \every other Monday." These could be accommodated by allowing wild-cards in timeofday and date speci cations and extending the language in various other ways.
6 Interpreting Adage Constraints In this section, we demonstrate that our language subsumes the constraint language of the current Adage design[SZ97a] by showing a translation of Adage constraints into our language. Since the Adage constraint language does not have a formal syntax or semantics, we cannot do this via a formal translation. We will simply illustrate the translation by examples.
6.1 Level and Category Comparisons
The Adage designers provide a simple language for comparing the level and category attributes of entities. For example, they permit the following comparisons between two labels L and M, where a label contains the level and role attribute of an entity. Intuitively, L is the label of the requesting principal p and M is the label of the designated target t. The translation of the operations in this set are straightforward. For example, L EQ M requires that the con dentiality levels, integrity levels, and roles all match. In our language this translates to: ILEVEL (THIS-P) == ILEVEL (THIS-T) AND CLEVEL (THIS-P) == ILEVEL (THIS-T) AND ROLES (THIS-P) == ROLES (THIS-T).
The Adage expression L DOM roles. We render this as:
M
only considers the con dentiality levels and
CLEVEL (THIS-P) > CLEVEL (THIS-T) AND ROLES (THIS-T) SUBSET ROLES (THIS-P)
The other level and category comparison operators are handled similarly.
30
Draft.
6.2 History Comparison Relations
In this category, three operations are de ned: HASDONE, NEVERDID, and NEVERUSED. These have to do with the history of requests which have been granted. Our history manipulation sublanguage is much richer, but handles these easily. Here the arguments are principals (P), actions (A), and targets (C). Adage version
Our translation
P HASDONE A
A IN ACTS (RESTRICT-P (H, P))
P HASDONE A TO C
A IN ACTS (RESTRICT-T (RESTRICT-P (H, P)), C)
P NEVERDID A
NOT A IN ACTS (RESTRICT-P (H, P))
P NEVERDID A TO C P NEVERUSED C
NOT A IN ACTS (RESTRICT-T (RESTRICT-P (H, P)), C) NOT C IN TGTS (RESTRICT-P (H, P))
6.3 Exclusivity Constraints
Exclusivity constraints in Adage are used to enforce separation of duty and two person control. Only two exclusivity constraints are de ned: NOTWITH and ATMOST N. T NOTWITH U means that roles T and U may not both appear in a principal's label at the same time. ATMOST N means that no more than N principals may be acting in a role r at a particular time. Adage version
Our translation
T NOTWITH U
FORALL p in ALL,
ATMOST N
NOT (p IN PRINS (T) AND p in PRINS (U)) ATMOST N p in ALL, p IN PRINS (r)
6.4 Trust Relations
Our current model does not encompase all of the various trust metrics envisioned in Adage. We only allow the speci cation of trust levels on cells and the constraints relating to the introduction chain for a principal. Thus, we don't currently have mechanisms for modeling the Adage constraints relating to age or quality of a chain or the number of introductions of a principal. These could be added by complicating our model. We equate their notion of citizenship with the cell of origin of a principal. Thus, we can model their notions of CITIZENSHIP and LENGTH.
31
Draft.
Adage version
CITIZENSHIP P LENGTH
Our translation
ORIGIN (P) LEN (CHAIN (P))
6.5 Combining Relations
We support the all of the Adage Boolean operators for combining relations as the Adage design, and add the implication opertor.
6.6 Component Modi ers
The component modi ers in the Adage authorization language provide a means of qualifying entity references within an Adage constraint expression. Some of these, like quanti ers, do not have meaning independent of their context of use. For example, MEMBER (T) can be used anywhere a principal name can be used and means \any member of team T." Thus, we would translate: MEMBER(T) HASDONE A to: EXISTS p in T, A IN ACTS (RESTRICT-P (H, p)),
and OTHER(T) HASDONE A to: EXISTS p in T, NOT (p == THIS-P) AND (A IN ACTS (RESTRICT-P (H, p))).
For several other Adage component modi ers, we have direct translations: THIS becomes THIS-P and TARGET becomes THIS-T. Thus, except for several of the proposed Adage relations relating to trust, our language subsumes that of the current Adage design. The additional relations relating to the age and quality of a trust chain could be added by complicating our semantics somewhat.
7 Conclusions We believe that the constraint language described above is a useful vehicle for expressing the sorts of constraints envisioned in the Adage design. Our language can be given a rigorous formal de nition and is more expressive than
Draft.
32
the current rather ad hoc collection of constraint cliches de ned for Adage. We believe that we can express most constraints currently expressible within Adage and many more within a context which is more rigorous. However, our language is still under development. There are some useful constraints which we cannot yet express. Our goal is to investigate the utility of our language by applying it to the formalization of some realistic security policies.
Draft.
33
References [BY97] William R. Bevier and William D. Young. Principles of authorization in Adage. Technical Report ??, Computational Logic, Inc., February 1997. [FCK95] D. Ferraiolo, J. Cugini, and D. Kuhn. Role-based access control (rbac): Features and motivations. In Symposium on Security and Privacy. IEEE, May 1995. [SZ97a] R. Simon and M.E. Zurko. Adage: An architecture for distributed authorization. Technical report, Open Group Research Institute, 1997. http://www.opengroup.org/www/adage/adage-archdraft/adage-arch-draft.ps. [SZ97b] Rich Simon and Mary Ellen Zurko. Separation of duty in role-based environments. In Proceedings of the Computer Security Foundations Workshop X. IEEE Computer Society, 1997. to appear.
