Status Based Access Control
Venkata Marella
Introduction
• This model is applicable in situations where
- access policy information may be distributed and
independently maintained.
-the permissions to access the resources change
frequently.
- of agents that request access to protected resources,
are important in rendering a decision on allowing the
requested access or not.
- Access control checker can intelligently determine the
authorization that hold at any instance of time
• Challenge: Size, Complexity and dynamic nature of
some distributed systems.
• Key feature of SBAC model is that a decision on an
agent’s request to access is determined by considering
the agent’s ascribed-status, the agent’s action status and
any additional conditions of relevance in answering the
access request.
• Ascribed Status+Action Status=Overall status
Ascribed Status
• an ascribed-status is associated with a collection of
agents that is formed on the basis of some common
criterion that the agents of the collection share.
– Particular role
– A categorization of agents as a reason of sharing
common attributes
– Trustworthiness
– Discretionary assignment of agents to a group.
Action Status
• An agent’s action-status is determined from a history of
the deliberative actions performed by the agent
• An agent is viewed as a rational entity that can, within
certain constraints, choose the actions it performs.
• As access to resources is determined from an agent’s
status level, it immediately follows that, in SBAC, an
agent can determine its access to resources because
the agent can choose the actions it performs and thus its
action-status.
Example
• A human agent who is under eighteen years of age. The
agent’s age is the basis for an ascribed-status of minor(
not deliberate).
• Now, suppose that the agent performs the deliberative
action of stealing a car and assume that no mitigating
circumstances apply to excuse the act of stealing(
deliberate).
• Then, the ascribed-status of minor together with the
deliberative action of stealing a car (we assume that the
action is not coerced)might give the agent an overall
status of young offender
• The status of young offender may be used as a basis for
determining what actions an agent with young offender
status can and cannot do.
• For example, agents with the status of young offender
may be subject to a curfew order and, as a
consequence, the agent may not be permitted to leave
his/her registered address in the hours between 6 p.m. in
the evening and 8 a.m. on the following day
• The ascribed-status and action-status of an agent u that
requests to access a resource r is used to determine
what actions u is authorized to perform on r.
• Access control models, like SBAC, that take agent
actions into account and that allow agents to manage, to
some extent, their access to resources will be
increasingly important in distributed applications, such as
secure e-trading and e-contracting.
• Notions like job functions and roles are often of
peripheral (or no) significance.
• Instead, criteria such as the quantity of units ordered by
a customer agent via acts of purchasing may be used as
the basis for determining access to resources
Example
• Customers ordering large volumes of merchandise may,
from their history of purchases, be determined to have
preferred status and, as a consequence, may be
permitted to access special offers information that is not
accessible to customers without preferred status. By
addressing such requirements, the SBAC model
contributes to work by the access control community that
aims to increase the functionality and application of
access control models.
Important Issues
• dealing with changing access control
requirements that
can
be
effected
autonomously
• the identification of information resources in
distributed systems that may be used for
evaluating access requests
• the composition of SBAC policies
- we make use of the primitive notion of an event and
we show how a finite and efficiently implementable
axiomatization of an event-based, typed logical theory
can be constructed for dealing with changing access
control requirements.
- we introduce Identification-based Logic Programs
(IBLPs)
- we define a number of algebras for flexibly
composing SBAC policies (represented as IBLPs).
• The SBAC model and SBAC policies are specified in a
language that has a purely declarative semantics and
that can be directly translated into an executable form for
which efficient, sound, and complete operational
semantics exist for access request evaluation.
• IBLP language is based on a nonmonotonic semantics
that provides a basis for accommodating changing policy
requirements and for defining an access control checker
that is able to reflect upon its knowledge and to change
an access control policy dynamically and autonomously
in response to changes in its knowledge base.
Identification Based Logic Program
• Identification-based Logic Programs (IBLPs).
IBLPs are an annotated form of logic programs that allow
independently maintained and distributed information
sources to be specified and referenced in the process of
access request evaluation.
• IBLPs are based on a syntactic variant of normal logic
programs.
Definition 1. A normal clause is a formula of the form:
A ← A1, . . . , Am, not Am+1, . ., not Am+n (m≥ 0, n ≥ 0).
• A normal logic program is a set of normal clauses.
• The head A of the clause and each Ai are atoms
• A1, . . . , Am are called “positive literals”, and not Am+1, .
. . , not Am+n are “negative literals”; not denotes
negation-as-failure.
• A clause with an empty body is a fact.
• Rule is a non empty body.
• The literals are also known as conditions of the clause.
• We denote variables in clauses by using symbols that
start with a letter in the upper case; we denote constants
by using symbols that start with a letter in the lower
case.
• Each atom in the body of a clause is annotated
with the name of a uniquely identifiable
module, which may be stored on any file
server called Uniform Resource Identifiers
(URI).
• Uniform resource identifiers (URIs) provide a
unique global identity for referencing IBLPs.
• Definition 2: Let R be a finite set of URIs. An
identification-based clause is a formula of the following
form (m≥ 0, n ≥ 0):
•
A ← A1⇐ v1, . . . , Am⇐υm, not Am+1⇐υm+1, . . . , not A1
Am+n⇐υm+n
where the head A and each Ai (1 ≤ i ≤ m+ n) are atoms,
and each υi (1 ≤ i ≤m+ n) is a URI in R.
An IBLP is a finite set of identification-based clauses.
where δ is a mapping δ : R −→ {P1, . . . , Pn}.
• Ai⇐υi is true (provable) iff Ai is true (provable) with
respect to the IBLP δ(υi), and not Ai⇐υi is true (provable)
iff Ai is not true with respect to δ(υi).
• Definition 3: Let R be a finite set of URIs and P1, . . . , Pn
be IBLPs. An IBLP configuration is a pair (R, δ) where δ
is a mapping δ : R → {P1, . . . , Pn}.
• Definition 4:
Let (R, δ) be an IBLP configuration, and let ui be a URI in
R. ∆υi denotes the normal logic program obtained by
replacing every occurrence of an atom of the form p(t1, .
. . , tk) ⇐ υ in the IBLP δ(υi) by the atom p:υ(t1, . . . , tk),
and every occurrence of an annotated atom of the form
p(t1, . . . , tk) in the IBLP δ(υi) by the atom p:υi(t1, . . . ,
tk). Let R = {υ1, . . . , υn}. The reduction of (R, δ), written
1(R, δ), is the normal logic program 1υ1 ∪ · · · ∪ 1υn.
• Definition 5: Let (R, δ) be an IBLP configuration. M is an
identification based (IB) stable model of (R, δ) iff M is a
stable model of the normal logic program ∆(R, δ).
• Definition 6: Although a reduction generates a normal
logic program from an IBLP by translating all URIannotated atoms to unannotated atoms, the IBLP syntax
is not redundant: a p(t1, . . . , tk)⇐υi condition in an IBLP
has an operational meaning as well as a logical
meaning.
SBAC MODEL AND POLICIES
• SBAC model and SBAC policies
- A countable set O of object identifiers.
- A countable set A of named actions
-A countable set L of status level identifiers
-A countable set E of event identifiers.
- A countable set U of agent identifiers.
- A countable set T of time points.
• An object is any thing that store information. an IBLP, a
database, individual facts within a database. All objects
have unique identity that is invariant; some object may
have properties.
• The set A of named actions includes
- the actions that may perform to change the status
-the actions the agent can perform as a
consequence of enjoying a particular status.
• A status level is a named position of an agent that is
relative to other status levels
of interest in a specific domain of discourse.
Example:
• 1.) Preferred Customer 2.) Ordinary Customer.
• Events are happenings at an instance of time. We adapt
a one point discrete view of time, with a beginning and
no endpoint.
• We assume that the time is bidirectional so that
proactive and post active may be made to represent the
access policy requirements and so that past, present
and future times can be used in our model as a basis to
make decisions.
• Preauthenticated agents may evaluate queries on
information sources protected by SBAC policies
expressed using IBLPs.
• An authorization is a 4-tuple (u, a, r, i) where u ∈ U is an
agent identifier, a ∈ A is an access privilege, r ∈ O is the
resource u requests to retrieve, and i ∈ O is the IBLP
from which u requests to retrieve r in i.
- how a history of events, relating to individual agents, is
represented as a set of facts.
- we use IBLP rules to express the core logical axioms
for our SBAC model
- we describe the formulation of a set 8 of IBLP rules
Event Description in IBLPs
• An agent’s access to the information resources that are
maintained by an organization Ω will depend, in part,
upon the transactions the requester agent engages in
with Ω. These transactions are expressed via a set of
application-specific security event descriptions (SEDs)
Definition:
• A security event description (SED) is a finite set of
ground 2-place facts (atoms) that describe an event,
uniquely identified by , i ∈ N, and which includes three
necessary facts, and n non-necessary facts (n ≥ 0).
• The three types of necessary facts in a SED and their
intended meanings are as follows:
—MOD(ψ-λ-φ) = happens(ei, ti) : the event ei happens
at time tj.
—MOD(ψ-λ-φ) = act(ei, al) : the event ei involves an
action al.
—MOD(ψ-λ-φ) = agent(ei, um) : the event ei involves the
agent um.
The happens(ei, ti) , act(ei, al) and agent(ei, um) facts in
an SED are used to represent a happening ei at a time ti
of act al performed by an agent um
Example
• Consider the following SED:
• {happens(e1, 20060612), agent(e1, bob), act(e1,
depositing), object(e1, a1), amount(e1, 1000)}.
• This SED describes an event e1 that happens on 12th
June 2006, and involves the agent Bob depositing an
amount of 1000 Euros into an object. bank account)
denoted by a1. The amount(e1, 1000) fact and the
object(e1, a1) fact are non-necessary facts.
Logical Axioms in IBLPs
• An agent U is currently assigned the status level L if an
event E happened at a time Ts, which is earlier than the
current time T, and resulted in the initiation of U’s
assignment to L, and this assignment has not been
ended before T as a consequence of an event E′
happening at a time T′ between Ts and T that causes U’s
assignment of the status level L to be terminated.
Proper Axioms
—A set of rules (AUX) that define the auxiliary predicates
that appear in the axioms
—A set of rules that specify permission-level
assignments (PLA);
—A set of rules that define denial-level assignments
(DLA);
—A set of rules (ACC) that are meta-level policy rules
—A (singleton) set of rules (AUT H) that specifies the
authorizations defined by a policy.
Extended SBAC
• In extended SBAC, we consider promissory actions and
hypothetical actions.
• A promissory action is a promise by an agent to perform
an action at some future time, that is, an agent may
promise to join a bank’s loyalty scheme by a set date.
These are useful in assigning temporary assignment of
status.
– Negative Promissory Actions
– Positive Promissory Actions
• Positive Promissory Actions: A positive promissory action
is an action of promising that an agent U makes at time
T1 that by some future time point T2 an action A will be
performed by U.
The following variant of the axiom may be used to
assign an agent U to a status level L1 on the basis
of U’s (positive) promissory action:
–
–
–
–
–
–
sla(U, L1) ← current time(T),
happens(E1, T1), agent(E1,U),
pp act(E1, A), T1 ≤ T,
sla init(E1,U, A, L1, T1),
not ended sla(U, L1, T1, T),
not expired sla(E1, T).
• Negative Promissory Actions: A negative promissory
action is an action of promising that an agent U makes at
time T1 that until some future time point T2 an action A
will not be performed by U.
–
–
–
–
–
sla(U, L1) ← current time(T),
happens(E1, T1), agent(E1,U),
h act(E1, A), T1 ≤ T,
sla init(E1,U, A, L1, T1),
not ended sla(U, L1, T1, T).
Practical Considerations
• On general complexity issues, we note that the key
decision problem of interest in the context of SBAC
policies is the problem of deciding whether a particular
instance of authorized is true in the IB-stable model for
an IBLP configuration.
• Four test for practical implementation
– Test 1. Query evaluation on a database db stored on a single
machine without an SBAC policy used to protect db.
– Test 2. Query evaluation on a database db protected by an
implementation of an SBAC policy and stored on the same
machine as db.
– Test 3. Status level computations using an SBAC policy that
accesses information from multiple distributed sites.
– Test 4. Remote access to a file of facts.
Two key observations emerge from our analysis of the
results generated from the testing:
- Using SBAC policies to protect information sources imposes
negligible extra overheads.
- Although communication costs dominate CPU costs dominate
CPU costs, the evaluation of realistic distributed computations
can be performed with adequate efficiency for realistic SBAC
policies.
SBAC Vs RBAC
• SBAC Model generalizes some RBAC Models.
• In RBAC, agents are assigned to one specific type of
ascribed status( i.e. role); once the role assignment is
made to the agent this persists as long as the security
administrator.
• SBAC allows any number of deliberate actions to be
performed by the agent to be performed by requester
agent.
• In constrained RBAC, contraints may be used to express
higher-level policy requirements that agent-role and
permission-role assignments.
• In SBAC, ACC is used for meta-policy specification, and
constraints, such as separation of status, can be
naturally accommodated.
• In contrast, in our approach, security administrators
define access control policies using predicates of their
own choosing , and test for stratifiability of policy
specifications.
Conclusion
• SBAC policies are appropriate to use in dynamically
changing, distributed computing contexts in which, for
instance, the notion of a job function does not
necessarily apply and where it is important to
accommodate rational agents that can pursue individual
goals rather than performing a particular function within a
particular organizational structure.
References
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
ABADI, M., BURROWS, M., LAMPSON, B. W., AND PLOTKIN, G. D. 1993. A calculus for access
control in distributed systems. ACM Trans. Program. Lang. Syst., 15, 4, 706–734.
ANTONIOU, G. AND VAN HARMELEN, F. 2004. A Semantic Web Primer. MIT Press.
APT, K. 1997. From Logic Programming to Prolog. Prentice Hall.
APT, K. AND BEZEM, M. 1991. Acyclic programs. New Generation Comput., 9, 3/4, 335–364.
APT, K. R. AND BLAIR, H. 1990. Arithmetic classification of perfect models of stratified programs.
XIII, 1–17.
BACON, J., MOODY, K., AND YAO, W. 2002. A model of OASIS RBAC and its support for active
security. ACM Trans. Inf. Syst. Secur., 5, 4, 492–540.
BARAL, C. AND GELFOND, M. 1994. Logic programming and knowledge representation. JLP
19/20, 73–148.
BARKER, S., LEUSCHEL, M., AND VAREA, M. 2004. Efficient and flexible access control via logic
program specialisation. In Proceedings of the ACM/SIGPLAN Workshop on Partial Evaluation
and Semantics-Based Program Manipulation (PEPM’04), 190–199.
BARKER, S., LEUSCHEL, M., AND VAREA, M. 2008. Efficient and flexible access control via Jones
optimality logic program specialisation. Higher-Order Symbol. Comput. 21, 1–2, 5–35.