PolicyMorph: Interactive Policy Transformations for a Logical Attribute-Based Access Control Framework

Abstract

Constraint systems provide techniques for automatically analyzing the conformance of low-level access control policies to high-level business rules formalized as logical constraints. However, there are likely to be priorities for solutions that are not easy to encode formally, so administrator input is often important. This paper introduces PolicyMorph, a constraint system that supports interactive development and maintenance of access control policies that respect both formalized and un-formalized business rules and priorities. We provide a mathematical description of the system and an architecture for implementing it. We constructed a prototype that is validated using a case study in which constraints are imposed on a building automation system that controls door locks. PolicyMorph advances the state-of-the-art in constraint systems by suggesting predictable policy model modifications that will resolve specific constraint violations and then allowing policy administrators to select the appropriate mo

Full text

Page 1

PolicyMorph: Interactive Policy Transformations for a
Logical Attribute-Based Access Control Framework
Michael LeMay, Omid Fatemieh, and Carl A. Gunter
University of Illinois at Urbana-Champaign
ABSTRACT
Constraint systems provide techniques for automatically analyzing
the conformance of low-level access control policies to high-level
business rules formalized as logical constraints. However, there
are likely to be priorities for solutions that are not easy to encode
formally, so administrator input is often important. This paper in-
troduces PolicyMorph, a constraint system that supports interac-
tive development and maintenance of access control policies that
respect both formalized and un-formalized business rules and pri-
orities. We provide a mathematical description of the system and
an architecture for implementing it. We constructed a prototype
that is validated using a case study in which constraints are im-
posed on a building automation system that controls door locks.
PolicyMorph advances the state-of-the-art in constraint systems by
suggesting predictable policy model modifications that will resolve
specific constraint violations and then allowing policy administra-
tors to select the appropriate modifications using knowledge that is
not formally encoded in the constraint system.
Categories and Subject Descriptors:
Systems]:Security and Protection—Access controls;
[Management of Computing and Information Systems]: Secu-
rity and Protection
General Terms: Security
Keywords: attribute based access control, policy administration,
separation of duty, constraints
D.4.6 [Operating
K.6.5
1.INTRODUCTION
Many of the challenges that arise during the development and
maintenance of an access control policy are caused by the inability
of the policy administrator to correctly translate high-level busi-
ness requirements into low-level access control policies that can
be implemented in an Access Decision Function (ADF). Several
approaches to this problem have been explored, such as improv-
ing the policy languages themselves to provide more direct ex-
pressions of business requirements. Role-Based Access Control
(RBAC) and Attribute-Based Access Control (ABAC) languages
are representative outcomes of this line of investigation [18, 15].
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
SACMAT’07, June 20-22, 2007, Sophia Antipolis, France.
Copyright 2007 ACM 978-1-59593-745-2/07/0006 ...$5.00.
Another common approach uses constraint languages to test prop-
erties of an ADF and point out violations to the policy adminis-
trator [11, 7]. Because constraint languages can be very expres-
sive, they are able to encode many business rules directly, but such
high-level constraints cannot be used to directly implement an ADF
because they specify what access control policies satisfy the busi-
ness requirements, without actually selecting any particular policy
from the (usually infinite) space of acceptable ones. Thus, most
constraint checkers simply report constraint violations for the for-
malized business rules. This generates a substantial burden on an
administrator because he must not only resolve the violations man-
ually but must also deal with all of the solution priorities that, for
one reason or another, were not formalized within the constraint
system. Another, more subtle, point is that business rules are often
flexible: exceptions are sometimes made, and a burdensome rule
may be ignored or changed. Thus the process of selecting an ADF
in light of business rules benefits from formalization and automated
support, but also requires significant human input.
In this paper we introduce a system called PolicyMorph that
helps administrators interactively assess ABAC access control poli-
cies with respect to logical constraints. This is, PolicyMorph not
only reports constraint violations, but also formulates suggestions
on how to address common types of violations. It then prioritizes
those suggestions, presents them, and allows the administrator to
evaluatetheeffectofeachsuggestionandimplementthesuggestion
that produces the most desirable outcome. In particular, Policy-
Morph allows the administrator to evaluate the desirability of each
option, without forcing him to encode all relevant constraints in a
formal language. This provides a middle ground between a fully
automatic system that places on the administrator a high burden of
formalization and a largely manual system that provides little help
in discovering and resolving specific violations.
To make these concepts more concrete, consider an access con-
trol policy for Personally Identifiable Information (PII) contained
in an online retailer’s database and regulated by that organization’s
privacypolicy, whichsetsforththebusinessrequirementsthatregu-
late the processing and storage of the PII collected from customers.
Other works have explored the formal semantics of privacy poli-
cies and explain how to decompose policies into individual goals
that can be analyzed further [1, 6, 14]. These goals can be easily
converted into logical constraints over an ABAC policy. For ex-
ample, consider the privacy goal “maintain confidentiality of cus-
tomer information from third party partners and marketing.” Let us
assume that some employees hold responsibilities in multiple ar-
eas, such as both marketing and information systems support (IS).
As a part of their IS duties, such an employee could be responsi-
ble for the maintenance of a customer email list. Unfortunately,
her membership in the marketing department would disqualify her

Page 2

from this role according to the privacy rule. The constraint checker
can easily detect this violation, but it is unlikely to know how to op-
timally transfer the responsibility for managing the customer email
list, since workload information, employee preferences, and other
external considerations are rarely encoded into the systems hosting
an access control policy. However, a human policy administrator is
likely to have access to such information and can easily select be-
tween the employees who could be assigned to that task. Thus, the
administrator would be aided by an analysis system that presents a
list of other employees to whom the responsibility could be trans-
ferred, allowing him to make the final selection. On the other hand,
if this re-assignment is viewed as impractical or excessively ex-
pensive, then the administrator may instead choose to adjust the
business rules, perhaps by accepting a weaker level of protection in
which the employee is asked to personally enforce the rule.
Two of the fundamental components in PolicyMorph are its logi-
calABACpolicylanguageanditslogicalconstraintlanguage. Both
of these are based on order-sorted first-order logic [16], which is
capable of supporting very expressive policies [10]. We then de-
scribe our interactive environment for resolving constraint viola-
tions and provide examples of policies where an administrator’s
humanknowledgeandpreferencescanbeusedtoresolveconstraint
violations with the help of PolicyMorph’s suggestions and analysis.
This analysis is complicated by the fact that PolicyMorph policies
can use dynamic contextual information from external sources to
make access decisions. We show how this functionality can be sup-
ported without significantly complicating policy definitions, and
while still preserving safety with respect to constraints. In partic-
ular, in one of our examples the location of a subject represented
within the access control system is inferred using presence infor-
mation from an instant messaging protocol and has actually been
implemented in our prototype. We demonstrate how our proto-
type operates as an access decision function using a representative
policy for a building automation system in a sophisticated, object-
oriented application, and also demonstrate our interactive policy
administration tool using that policy.
The rest of this paper is organized as follows. In Section 2 we
defineouraccesscontrolpolicyandconstraintlanguages. Inasimi-
lar fashion, Section 3 presents our transformation framework. Sec-
tion 4 describes an architecture and prototype implementation of
these systems. Section 5 describes an evaluation of the approach
using the prototype to carry out a case study. Section 6 discusses
related work. Section 7 concludes the paper and summarizes our
future directions.
2.POLICIES AND CONSTRAINTS
In this section we present the major components of our system,
namely the access control policies, the models needed to interpret
them, and the the constraints to be imposed on them. We assume
that the reader is familiar with first-order logic.
Access Control Policies.
A low-level access control policy comprises a set of predicates
with a predefined signature that corresponds to the elements of an
access decision request. To accommodate this signature, policies
use a variety of sorts, including S (agents or principals σ, com-
monly known as subjects, that perform actions on objects), O (ob-
jects δ upon which subjects perform actions), Entities (a super-sort
of both S and O), Actions (η), Contexts (runtime information γ that
can be incorporated into access decisions), and Justifications (com-
pound terms κ that specify every reason that a positive access deci-
sion was provided). More formally, a policy is a first-order formula
which can be represented as follows:
f ⇒ Permitted(σ,δ,η,γ,κ)
Whenever this formula is satisfied, it indicates that the correspond-
ing access request should be granted. To understand the role of κ,
one should consider it to be an output of the predicate, rather than
an input parameter to be tested. It is not used in the decision mak-
ing process, but is simply unified with the reasons that a positive
access decision were made, as discussed in more detail later.
Members of Contexts represent a specific set of conditions that
canbedefinedorsensedbytheoverallsystemintowhichtheaccess
control system is integrated. Each context is a relation that maps
arbitrary, application-defined keys to arbitrary values:
∀γ ∈ Contexts. γ ⊆ CtxKeys × CtxValues,
where CtxKeys and CtxValues are application-defined sorts. Each
context relation is customarily a partial function. However, the pol-
icy for each application has the freedom to define its own mecha-
nisms for representing and processing contextual information.
Elements of Justifications are used to convey the exact reasons
that a particular access decision is granted. Using a backtracking
engine like the one built into Prolog interpreters [17], it is possi-
ble to determine all possible justifications for a particular access
decision.
Each element of Justifications can be formally expressed as a
set of individual reasons for why a positive decision was made, al-
though the same formulation could also be used to justify negative
decisions if our system supported such decisions. Justifications are
simply sets of reasons and sets of labels. We now present each
reason currently recognized by our framework:
∀ε ∈ Entities,∀α ∈ A.
HasAttr(ε,α) ∈ Reasons ∧
NotHasAttr(ε,α) ∈ Reasons
The HasAttr reason specifies that the entity ε possesses a spe-
cific attribute α, whereas NotHasAttr signifies that ε lacks α. This
convention is also used for the following reasons. Any reason with
a name prefixed by “Not” carries the opposite meaning of the pos-
itive reason with the same parameters.
∀ε ∈ Entities,∀α ∈ A.
HasSubAttr(ε,α) ∈ Reasons ∧
NotHasSubAttr(ε,α) ∈ Reasons
The HasSubAttr reason specifies that the entity ε possesses an
attribute that has the specified attribute α as a direct or indirect
parent in the attribute hierarchy (the hierarchy will be described
later and is reflexive, so that the specified attribute itself is included
in the set of acceptable attributes).
∀ε ∈ Entities.
IsNamed(ε) ∈ Reasons ∧
NotIsNamed(ε) ∈ Reasons
The IsNamed reason is required because policies can take the
exactidentityofthesubjectorobjectspecifiedinanaccessdecision
request into consideration when making the decision.
These reasons can be used to describe the operation of typical
policies supported by our system. Specifically, the framework sup-
ports permission terms that consider the association or disassocia-
tion of an attribute to an entity, or the identity or non-identity of an
entity when making an access decision. However, administrators
are not restricted to those policies that can be characterized by this
justification framework. Any term that is not specially supported
by the framework will be wrapped in a generic reason that simply
conveys the term verbatim.

Page 3

Model.
An access control model defines parameters used by an access
control policy to produce access decisions. It comprises a set of
entity declarations, a set of attributes, an attribute hierarchy defini-
tion, and an assignment of attributes to entities. Formally, we can
represent this as a 5-tuple:
Ψ = ?S,O,A,AH,AA?,
where S and O were explained previously, and:
• A is a sort containing attributes that can be assigned to enti-
ties.
• AH ⊆ A × A is a reflexive, transitive, and antisymmet-
ric relation defining a hierarchy over those attributes, where
(α1,α2) ∈ AH =⇒ α1is a sub-attribute of α2. This hierar-
chy can be used when making access decisions.
• AA ⊆ Entities × A is a relation which represents the assign-
ment of a set of attributes to each entity in the model.
Constraints.
Since access control policies in our system are expressed in first-
order logic, it is easy to express and test queries over those policies
using a backtracker that explores the state space of possible query
instantiations. We use a backtracker facility parameterized over
all entities to express high-level business requirements and other
constraints.
Each constraint must conform to the following template:
f ⇒ Undesirable(κ),
where f is any first-order formula, κ ∈ Justifications and the for-
mula is only satisfied if an undesirable access is allowed in the pol-
icy instantiation (combination of low-level policy and access con-
trol model) being tested and κ specifies the exact reasons that the
undesirable access was allowed. Using a backtracking engine, it
is possible to discover all such undesirable accesses. Again, κ is
actually an output from the constraint that encapsulates all of the
reasons responsible for the violation.
In brief, this allows us to impose high-level constraints on low-
level logical ABAC policies. Constraints are used to describe safety
properties of an access control policy in an inverted manner (i.e.
conditions or authorizations that should never be permitted in the
policy). Such constraints should be written in a predicate calcu-
lus, in general because they must preclude assignments that are not
known a priori. Typically, such constraints are checked whenever
the policy or model is modified and before the system is deployed,
to prevent the usage of any access control system that may violate
the constraints.
3.MODEL TRANSFORMATIONS
When constraints are violated, it is often possible to resolve the
violations by performing simple, predictable modifications to the
access control model in question. It is typical that some attributes
cannot be changed (like the age of the subject) whereas others can
be changed under suitable authority (like the task assignment or de-
partment of the subject). The latter are the focus of our transforma-
tions related to access control and constraint satisfaction. Our sys-
tem provides four predefined rules for modifying the model based
on constraint violations, but additional rules can be easily added to
the system. Regardless of the transformation rule in use, the over-
all transformation process is unmodified. Each set of transforma-
tions may resolve one or more violations, but it may also produce
new violations, so it is important to re-validate the constraints after
implementing transformations. The transformation process itself
is represented by a function that accepts the original model and a
transformation rule as arguments, and produces a modified model.
PolicyMorph provides an interactive environment in which: an ac-
cess control policy is analyzed with respect to a set of constraints,
violations are discovered, suggestions to resolve them are provided,
andtransformationsareappliedtoeliminatetheviolations. Wenow
outline the basic transformations and the way in which suggestions
are prioritized.
Basic Transformations.
The elimination transformation disassociates an attribute from
an entity:
Transform(?S,O,A,AH,AA?,Eliminate(ε,α)) =
?S,O,A,AH,AA − {(ε,α)}?
The introduction transformation associates an attribute with an en-
tity:
Transform(?S,O,A,AH,AA?,Introduce(ε,α)) =
?S,O,A,AH,AA ∪ {(ε,α)}?
The egress transfer transformation disassociates an attribute from
the entity specified in the reason and associates it with another en-
tity that does not already possess the attribute.
Transform(?S,O,A,AH,AA?,EgressTransfer(ε1,ε2,α)) =
?S,O,A,AH,(AA − {(ε1,α)})) ∪ {(ε2,α)}?
The ingress transfer transformation is the semantic complement of
the egress transfer, and is included for notational convenience. It
associates an attribute with the entity specified in the reason and
disassociates it from another entity that already possesses the at-
tribute. We will explain the purpose of each transformation below.
Since a justification is invalidated if any one of its reasons is in-
validated, the administrator is usually not required to implement a
transformation for every reason before the policy instantiation be-
comesconformant. Tominimizethenumberoftransformations, we
combine the reasons from all violations and sort them in decreasing
order according to the frequency with which they each occur. Then,
we iterate through the list and generate all possible transformations
that will eliminate the reason in question. The administrator is al-
lowed to evaluate the results of any of the suggested transforma-
tions and then implement the most desirable transformation. This
process continues until the administrator decides to re-evaluate the
policy’s conformance.
We define a function that suggests transformations to eliminate
a specific reason as follows:
SR : Reason → 2Transformers,
where Transformers is a sort containing all possible transformation
rules, containing at a minimum those just discussed. This func-
tion can be extended when additional transformation rules are in-
troduced into the system. We show the basic definition of the func-
tion here:
SR(HasAttr(ε,α))
=
{Eliminate(ε,α)} ∪
{EgressTransfer(ε,εd,α)|
(ε ∈ S =⇒ εd∈ S) ∧
(ε ∈ O =⇒ εd∈ O) ∧
α ? AA(εd)}
?
SR(HasSubAttr(ε,α))
=
(β,α)∈AH∧β∈AA(ε)
SR(HasAttr(ε,β)),

Page 4

where AA(ε) is the set of attributes assigned to ε by the relation
AA. You may have noticed that Eliminate is the functional com-
plement of Introduce, and EgressTransfer is the complement of
IngressTransfer. Thus, it should not be surprising that we use
Introduce and IngressTransfer as the suggested transformations for
negated reasons:
SR(NotHasAttr(ε,α))
=
{Introduce(ε,α)} ∪
{IngressTransfer(ε,εs,α)|
(ε ∈ S =⇒ εs∈ S) ∧
(ε ∈ O =⇒ εs∈ O) ∧
α ∈ AA(εs)}
?
SR(NotHasSubAttr(ε,α))
=
(β,α)∈AH
SR(NotHasAttr(ε,β))
Finally, SR does not produce any suggestions for IsNamed reasons,
since those reasons typically point to underlying problems in the
model (presence of a banned entity) or low-level policy. Neither
problem lends itself to an automated solution in our system.
Suggestion Prioritization.
As we will explain shortly, our tool presents potential transfor-
mations that will resolve constraint violations to policy administra-
tors. Unfortunately, an overwhelming number of possible transfor-
mations may be generated in large access control models, causing
policy administrators to abandon the tool or make non-optimal de-
cisions. Thus, we first prioritize reasons in justifications for vio-
lations in descending order according to the frequency with which
they appear in all the justifications. Then, for each of these rea-
sons, we prioritize the possible transformations and present the
most likely transformations to administrators first.
Unfortunately, it is not possible to formulate a general prioritiza-
tion scheme; a comparator must be defined that explicitly handles
each type of transformation in the system:
CompareSuggestion : Transformers × Transformers → {first,second},
where a result of first indicates that the first transformation rule
should be given precedence, and second indicates that the second
transformation should be given precedence.
Again, this comparator should be extensible and accommodate
the addition of new transformations, but we explain how it will
operate on the standard transformation types here.
Introductions and eliminations will always be given precedence
over transfers, since they do not interact with any entity in the sys-
tem except the one identified in the reason. Thus, they are less
likely to introduce new violations.
Ingress and egress transfers need only be prioritized among
themselves, since both types of transfers will never be suggested
for a single reason (besides, they are semantically equivalent).
In a well-defined access control model, attributes will typically
be transferred between entities with similar sets of attributes, since
these attributes should represent the similarity of the entities. In
our privacy policy example, the “customer email list administra-
tor” attribute should most likely be transferred to another entity
that already possesses attributes similar to those possessed by the
source entity. In this example, someone who already possesses the
IS departmental attribute is a likely candidate. Thus, we quantify
the similarity between entities specified in a transfer transforma-
tion and prefer transfers between similar entities. More formally,
we evaluate the following function on the two entities in the trans-
fer and prefer transformations that result in higher values for the
function:
EntitySimilarity : Entities × Entities → R,
where
∀ε1,ε2. EntitySimilarity(ε1,ε2) =
|{α|α1∈ AA(ε1) ∧ α2∈ AA(ε2) ∧
(α1,α) ∈ AH ∧ (α2,α) ∈ AH}|,
and AA and AH are drawn from the access control model.
Of course, this scheme could be greatly improved by consider-
ing how relevant attributes are to each other, so that in our example
the IS attribute is given more consideration than other attributes
when transferring the email list administrator attribute. Unfortu-
nately, this may require the policy administrator to specify these
relationships, although they could possibly be constructed by ana-
lyzing the correlation between attributes assigned to each object in
a representative model.
4. IMPLEMENTATION
To evaluate the constructs discussed in this paper, we imple-
mented a prototype access control engine. Several requirements
helped direct the system’s design. First, it must be straightforward
to design and encode policies, models, and constraints. Second, it
must be easy to evaluate the access control model using those con-
straints, and then to implement transformations to bring the access
control model into conformance. Finally, we needed a full-featured
foreign language API to demonstrate the usefulness of our access
control engine in a sophisticated, object-oriented security applica-
tion.
There are now several logical programming languages available
that could have potentially satisfied many of our requirements, but
we settled upon Prolog due to its maturity and popularity [17]. We
use the SWI-Prolog interpreter (swi-prolog.org) because it pro-
vides a sophisticated foreign language API, is freely available, and
has respectable performance [8].
Our system implements the major logical constructs discussed
previously, including support for context-aware policies. The for-
eign language API supports bi-directional data transfer, to allow
external programs to query the ADF, and to allow permission pred-
icates to utilize contextual information from external sources.
Our prototype system can serve at least two different purposes.
First, it can be used to ensure that policies conform to a set of con-
straintsrepresentingbusinessrequirements. However, itcanalsobe
used to evaluate the effects of business requirement changes on ex-
isting policies. To perform this evaluation, the administrator should
first ensure that the affected policy instantiations are compliant with
the original constraints. Then, they should re-evaluate those instan-
tiations using the new constraints. The violations discovered by the
system will inform the administrator of what new constraints will
necessitate changes in the policy instantiations, which can then be
used to evaluate the practical effects of the constraint changes on
the legacy policies.
4.1Access Control Policies
Policies must be written in Prolog as a number of predi-
cates. Each predicate must have a head (Prolog terminology
referring to the signature of the predicate) like the following:
permitted(Subj, Obj, Act, Ctx, Just), where Subj is a
subject, Obj is an object, Act is the action that is to be performed
by Subj on Obj, Ctx is the current context of the system, and Just
is an output variable to which a justification structure will be as-
signed whenever the rule is satisfied. The following rule is a fairly
complex and illustrative example. It specifies that professors are
allowed to access their secretaries’ resources:
permitted(entity(subject, ProfId, _), Obj,

Page 5

Act, Ctx, Just) :-
justification_none(prof_secretary_res, JN),
is_subject(Sec),
jb(subject_has_attr(secretary(ProfId),
Sec), JN, J0),
permitted(Sec, Obj, Act, Ctx, J1),
jb_join(J0, J1, Just).
Recall that in Prolog all of the terms separated by commas af-
ter the head and reverse-implication symbol (:-) must be satisfied
for the entire predicate to be satisfied. Multiple predicates with
the same name and number of arguments are joined into a logical
disjunction, so that the entire formula can be satisfied if at least
one predicate in the procedure is satisfied. Capitalized terms repre-
sent variables, whereas lowercase terms are simple values. Low-
ercase terms written in function notation are structures, such as
secretary(ProfId). Notice that structures may contain vari-
ables. We now describe each line individually, since this rule uses
some syntax that we have not yet introduced:
permitted(entity(subject, ProfId, ), Obj, Act,
Ctx, Just): The first argument uses Prolog’s ability to de-
compose structures within predicate heads. In our system, both
subjects and objects are represented using entity structures. The
first field of the structure indicates whether the entity is a subject or
an object. The second field identifies the entity, and the third field
may contain the set of attributes associated with the entity. It is not
necessary to populate the final field in normal usage, since helper
predicates are provided to populate that field whenever it becomes
necessary. In this case, we are only interested in the identity of the
person who must be a professor for the predicate to be satisfied, so
we extract the ID from the entity and refer to it as ProfId.
justification none(prof secretary res, JN):
an empty justification structure assigned to JN that assigns the
name prof secretary res to the predicate. The name is simply
used to record in a human-understandable format which predicates
played a role in deciding to allow this access if it is in fact
permitted.
is subject(Sec): Due to the backtracker in Prolog, this sin-
gle line will actually enumerate all subjects in the entity database,
unifying Sec with them individually. This line does not play a sig-
nificant role in deciding whether to permit the access, so it does not
contribute to the justification structure.
jb(subject has attr(secretary(ProfId),
Sec), JN, J0): Theinner
subject has attr(secretary(ProfId), Sec),
satisfied when Sec is the secretary of the professor identified by
ProfId.
The outer part of this line, jb(..., JN, J0), serves two pur-
poses. First, it interprets the inner part of the line as just discussed.
If the inner term is satisfied, the outer term will then add a reason
representing that inner part to the justification, unifying J0 with
the new structure. The outer term is satisfied iff the inner term is
satisfied.
Seven generic reasons of four major types are supported. They
correspond to the formal reasons discussed in previous sections:
Create
part ofthisline,
onlyis
(\)has attr(Type, Id, Attr): Specifies that the decision
was based on the fact that the entity with the given Type
(subject or object) and Id was associated (or not associ-
ated if the negation symbol \ is used) with the attribute Attr.
(\)has subattr(Type, Id, Attr): Specifies that the decision
was based on the fact that the entity with the given Type and
Id was associated (or not associated) with a sub-attribute of
Attr.
(\)is named(Type, Id): Specifies that the decision was based
on the fact that an entity with the given Type is or is not iden-
tified by the given Id. Typically, all three of the reasons just
presented identify one of the entities passed into the permis-
sion predicate producing the justification, but they can also
be applied to other entities in the system.
satisfied(Pred): This is a default reason that encapsulates a
predicate that does not correspond to any of the other reasons
just described.
In our example, the jb predicate adds the has attr(subject,
Sec, secretary(ProfId)) reason to the justification, where all
of the variables (capitalized terms) are replaced with the specific
terms that cause the larger term to be satisfied.
The next line in our predicate, permitted(Sec, Obj, Act,
Ctx, J1), is a chained reference to the permitted predicate, to de-
termine whether the secretary just selected has access to the re-
source in question. Notice that this invocation generates its own
justification.
The final line in the predicate, jb join(J0, J1, Just), sim-
ply merges the two justifications, J0 and J1, to form the single jus-
tification Just that is finally returned to the process invoking the
predicate. The merging process constructs a justification structure
containing a union of the labels and reasons from both justifications
being merged.
Contextual Information.
The previous rule did not explicitly deal with any contextual in-
formation. The next rule demonstrates how contextual information
can be used to make access decisions. This example is drawn from
an academic environment, and centers on an admissions committee
comprising both faculty and students. It specifies that students on
the admissions committee are permitted to enter rooms designated
for admission committee meetings only after the context indicates
that the system is at least 50% confident that all professors on the
committee have entered the room. The final confidence level is an
unweighted average of the confidence levels that each individual
professor on the committee is in the room. Thus, if the system is
100% confident that half of the committee members are present the
predicate will be satisfied, and so forth.
permitted(Subj, Room, enter, Ctx, Just) :-
justification_none(adm_comm, JN),
jb(object_has_subattr(adm_comm_rm, Room),
JN, J0),
jb(subject_has_subattr(adm_comm_mbr, Subj),
J0, J1),
(
jb(subject_has_subattr(professor, Subj),
J1, Just)
;
jb(adm_comm_meeting(Room, Ctx),
J1, Just)
).
We explain only the significantly different aspects of this predi-
cate here:
object has subattr(adm comm rm, Room): This predicate
only deals with admission committee rooms. Thus, this term fil-
ters out all irrelevant rooms by only accepting objects with an at-
tribute specifying that the room is a designated meeting place for
admission committee members.
subject has subattr(adm comm mbr, Subj): In a similar
spirit, this predicate filters out subjects that are not members of
the admission committee.