RelBAC is a new access control model that has gradually aroused the research interest in the domain of access control. But it is still not mature enough for industrial application due to its high logical complexity. In this paper, we present a framework to implement RelBAC . First, access control queries to RelBAC knowledge base (KB) are analysed and categorized into different queries as run-time or off-line. Then the necessary knowledge is studied to answer each type of query. We propose to separate the knowledge for run-time query, named as a complete ABox, from the classical RelBAC KB and store it in a relational database, so as to provide run-time answers within acceptable time. Last, a theorem is proved to backbone our method and an algorithm is proposed to calculate the complete ABox. This framework serves as a meaningful attempt to put RelBAC into practice.
Access control models evolute with the advances of technologies. The famous Role-based Access Control model RBAC [4] was proposed in the 20th century, has now flourished in practical access control systems such as in Windows operation systems. It evolves into different models such as ARBAC [11], GeoRBAC [3], ARBAC [8] etc.
As a new access control model, RelBAC [6] connects the subject that query to access the object with the permission as a binary relation. The model provides intuitive and straightforward semantics to home users without formal access control experiences. But RelBAC has not flourished as expected in industry solutions. What hinders the model from practical application is the shortage of background supporting mechanism, which is supposed to be the powerful reasoning services provided by description logic (DL) reasoners. There is no good enough general purpose reasoners for RelBAC yet.
In this paper, we propose a practical framework to implement RelBAC . The knowledge base (KB) of a RelBAC access control system can be classified into different parts, namely, organization, authorization, constraint and environment. Each part consists of its typical structured axioms or assertions. Such structures are studied and classified into run-time and off-line queries to the KB. We prove that to answer the run-time query, only part of the ABox assertions are necessary. An algorithm is proposed to populate individuals of concepts to build a complete ABox. Such ABox assertions are separated from the classical KB and stored directly in a relational database. Then query from end user and/or system can be parsed and distributed to different engines, i.e. the database query engine to provide run-time response and the reasoning engine to check off-line queries. The framework provides a practical path to implement RelBAC in industrial solutions.
The paper is organized as follows. Section 2 gives a glance in RelBAC model; Section 3 illustrate our framework; Section 4 shows our strategy to implement RelBAC ; and we conclude in Section 5. 2
Relation-based Access Control (RelBAC ) is an access control model introduced in [6] and formalized using the DL ALCQIBO as described in [16]. In this section, we will illustrate the basic RelBAC definitions and related access control policies. 2.1
As shown in the ER Diagram of Figure 1, what distinguishes RelBAC from other access control models is the way it models permissions. A PERMISSION is modeled as an operation that users (SUBJECTs) can perform on certain resources (OBJECTs). To capture this intuition, a PERMISSION is named with the name of the operation it refers to. The generalization (loops) on each component represents IS-A relations. Not only SUBJECT and OBJECT are organized along IS-A hierarchies but also PERMISSION. Together with RelBAC , a logic ALCQIBO extends the DL ALC [2] with qualified cardinalities, inverse roles, nominals and Boolean for roles (see [12, 10, 9] for extensions of DLs with Booleans between roles). As described in [1], ALCQIBO is applied in access control domain to formalize RelBAC .
ALCQIBO. The syntax of ALCQIBO is defined as follows.
C, D ::= A | ¬C | C u D | ≥ n R.C | {ai}
R, S ::= P | R− | ¬R | R u S where A ∈ NC, P ∈ NR, ai ∈ NI and n ∈ N.
A KB (KB) is a pair K = hT , Ai where T , called TBox, is a finite set of general concept inclusions (GCIs) of the form C v D and a finite set of general role inclusions (GRIs) of the form R v S, while A, called ABox, is a finite set of concept and role assertions of the form C(ai) and R(ai, aj ), with ai, aj ∈ NI.
The corresponding semantics (partial) of ALCQIBO is defined as follows. (R−)I := {(y, x) ∈ Δ × Δ | (x, y) ∈ RI }, (¬R)I := Δ × Δ \ RI , (¬C)I := Δ \ CI , (R u S)I := RI ∩ SI , (C u D)I := CI ∩ DI , (> n R.C)I := {x ∈ Δ | ]{y ∈ Δ | (x, y) ∈ RI and
y ∈ CI } ≥ n}, {ai}I := {aiI }.
An ALCQIBO-interpretation I = (Δ, ·I ) is said to be a model of a KB, K, iff it satisfies CI ⊆ DI , for all C v D ∈ K, RI ⊆ SI , for all R v S ∈ K, aiI ∈ CI , for all C(ai) ∈ A, and (aiI , ajI ) ∈ RI , for all R(ai, aj ) ∈ A. In this case we say that K is satisfiable and write I |= K. A concept C (role R) is satisfiable w.r.t. K if there exists a model I of K such that CI 6= ∅ (RI 6= ∅). Formal Specification. In RelBAC we distinguish five different kinds of specifications that, altogether, constitute an access control system: the organization information, the authorization policy, the control constraint, the environment factors and the administration query. RelBAC uses the description logic ALCQIBO to express each specification by associating a concept name to each SUBJECT and OBJECT while permissions are described by means of role names. 1. Organization, to organize the entities and relationships among entities into hierarchical structures with partial order. 2. Authorization, to declare the permissions from SUBJECT to OBJECT. 3. Constraint, to declare general regulations that existing and new authorization policies should follow. 4. Query, to check the instantiation or satisfiability of the current access control KB.
The first step of our work is to clarify the patterns latent in above specifications in order to analyze the difference of the reasoning services related to each pattern.
Based on the theory of RelBAC , we propose a framework towards the implementation of the theory. It consists of three layers coherent to a standard MVC structure, but specialized to fit the access control domain.
Figure 2 gives the conceptual model of the frame.
As is shown in the figure, the framework consists of three major components, interface, engine and KB. Let us get into the details of them one by one. format, thereafter be sent to responsible engines. Details of the formats and patterns will be discussed in Section 4.
RE It is the Reasoning Engine, that accepts OWL-API format reasoning tasks and provides reasoning services together with the interaction with the ontology KB(s).
QE It is the Query Engine that takes the database queries as input and provides necessary query answers via access to the database in the KB. KB It stores the knowledge necessary for the access control system functionality, such as the organization of the SUBJECT, OBJECT and PERMISSION; the authorization and constraint policies; the environment factors, etc. It is divided into two parts, the AK and DK, which stores the knowledge for different purposes.
AK It is the Administrative Knowledge base, aims at general policies that support the administrative queries. It usually interacts with RE as the reasoning background.
CK It is the Control Knowledge implemented via classical relational database techniques. Instantiated knowledge, such as the ABox assertion that ‘John is permitted to update the root path’ is stored here.
With the framework, the next step is to work out the details of each component. We will describe the theoretical details in the next section. 4
This section will focus on the theoretical aspects to implement the framework introduced above. The patterns are clarified for the knowledge in a RelBAC system. Then the distribution strategy is proposed in details. 4.1
One of the key issue to implement the framework is to clarify the possible knowledge patterns. In Section 2.2, knowledge has been classified into four categories. Here, we will identify the patterns from the categories. 1. Organization: In the access control terminology, SUBJECT, OBJECT and PERMISSION may be organized in a taxonomy along the IS-A relation [5]. An IS-A relation is represented as a concept (or role) inclusion axiom in RelBAC :
C v D or P v Q
(
S v ∀¬P.¬O or O v ∀¬P −.¬S which specifies that any SUBJECT in S is permitted to perform the operation (with the same name) P on any OBJECT in O. For easy reading purpose, it is transformed into a SWRL [14] rule as
S(?x), O(?y) → P (?x, ?y) Special cases exist for Formula (20), with alternation of the concept(s) with nominal(s), we have the following variations.
Moreover, in addition to the DL roles for PERMISSION, classical roles may also exist to describe binary relations between entities that is not a PERMISSION, such as ‘is-older-than’ or ‘has-published’ relation in a system with an academic background. The inverse role operator The number restriction operator ≥ is seldom used in organization. Its combination with the other operators will results in an axiom that could not be instantiated, as it puts restrictions on cardinality rather than fix individuals.
This is more likely to be used in the specification of constraints.
2. Authorization: It specifies a permission existing between a SUBJECT and
an OBJECT both on organization level or instance level in various of forms.
(
S v ∀¬P.¬{..., oj , ...} {..., si, ...} v ∀¬P.¬{..., oj , ...} where i, j are natural number indexes for individuals of SUBJECT and OBJECT. An authorization policy in the form of an ABox assertion P (s, o) is only a special case of Formula (200). 3. Constraint: It specifies the restrictions or regulations that the authorization policies should not violate. A constraint usually stays inactive in a running system. But when environment factors change, such as the rise of the system load, the crucial time point, the access behavior violation, etc. Therefore, the reasoning engine should check the consistency of the KB when new knowledge arrives or current knowledge updates.
Some of the most concerned constraints are: (a) Separation of Duties (SoD): It regulates the mutual exclusiveness of permissions. SoD lies in different levels and granularity. Given a set of positions S = {S1, . . . , Sn}, where each Si is a concept name, a SoD policy ‘a subject can take all the positions in S’, may take the form of an unsatisfiable compound role (in contrast to an atomic role).
Cnm m
G ( l Sij ) v ⊥
i=1 j=1
where Cnm is the binomial coefficient of ‘n choose m’. A special case of
Formula (
∃Pi.Oi v ⊥ n l i=1
n ≥ 2 P.(G
i=1 . (b) Chinese Wall (CnW): The Chinese Wall property regulates conflict of interest (CoI), that ‘the resources in the set of CoI could not be accessed by the same user’. Given a set of sensitive resources, O = {O1, ..., On}, and the corresponding operation P = {P1, ..., Pn}, a CnW policy may take the form as.
Specifically, when the operation remains the same, say P , then the
formula changes into
(30)
(
Control Query (CQ) It verifies wether a requester for the resource have or
not the permission to access certain number of objects. Given a SUBJECT
u, the query could be of the following patterns.
(a) whether a SUBJECT s has PERMISSION P on the OBJECT o;
(b) whether a SUBJECT s has PERMISSION P on the OBJECT in O.
correspond to the, so called, instance checking reasoning service:
Σ |=P (s, o),
Σ |=(∀¬P.¬O)(s).
(
Administrative Query (AQ) It checks the state of the access control system, such as (a) search for all the SUBJECT that has PERMISSION P on OBJECT o; (b) search for all the OBJECT that is permitted to some SUBJECT s via
PERMISSION P ; (c) whether the current system KB is consistent; (d) whether an intended policy implied in the KB; (e) whether an intended policy conflicts with the KB; (f) whether an intended policy irrelevant to the KB; (g) whether an intended update of environment violates the KB; (h) whether an intended update consistent with the KB; (i) whether an intended update irrelevant to the KB; The first two AQ’s lie in the reasoning of instance retrieval for a compound concept, say ∃P.{o} and ∃P −.{u}, as the following, retrieve all SUBJECT u thatΣ |= ∃P.{o}(u)
retrieve all OBJECT o thatΣ |= ∃P −.{u}(o) Here the compound concept is not bounded to permission, environment attributes could be considered too. Therefore the concept on the right side of |= could be conjunction or union of multiple concepts. The third AQ lies in consistency checking for the KB.
Σ |= ⊥ If there is no model exists for Σ, the answer is inconsistent.
DL reasoning assumes an Open World Assumption [2], which does not
imply a negation if the positive is not a deduction result, and vise versa.
This means we cannot conclude that some policy (in format of an
axiom) is unsatisfiable if it is not deduced from the KB. Therefore, given a
concerned policy as an axiom A, the fourth AQ could be answered with
a consistency checking as Formula (
The last three AQ’s are similar to AQ 4-6, with the only difference that
instead of adding a new axiom A, an existing entity e, say a SUBJECT,
OBJECT or PERMISSION, will be alternated by a ‘new’ entity with its
attribute changed, i.e. all appearance of e will be replaced with an e0.
Then the ‘new’ KB is checked in respect of Σ.
(
As mentioned for Formula (
Here in this subsection, nine patterns are discovered in Formulae (1 to 9). Different strategies will be applied on the patterns to enhance the run-time performance of the system. 4.2
As is shown in Figure 2 in Section 3, the queries through interfaces are transformed by the Parse Engine PE and then transported to the other engines to process via interaction(s) with the KB. However, a general purpose reasoner such as [15], [7] and [13] does not provide good enough responses to RelBAC queries. To be precise, they cannot reason on RelBAC with the logic ALCQIBO., not to say provide run-time answers. How to transform RelBAC into a form that could be operated by DL reasoners will not be covered for page limits. The aim of this paper is to make the system work at run-time.
The strategy is to distribute the queries to different engines, i.e. RE or QE. With the pattern clarification of RelBAC in Section 4.1, we distinguish the knowledge patterns into nine formulae (Formula 1 - 9). We see that only the CQ’s relate to run-time queries. Moreover, they are all related to instances. Therefore, we design an algorithm to populate all the individuals inside the KB into possible concepts which named as ABoxing, and get to a theorem as the following.
Definition 1. The ABox assertion set A of an ontology O is complete, if and only if any ABox assertion α implied by O is explicitly inside A.
A = {α|α is an ABox assertion, O |= α}
Then we have the following theorem which gives that, Theorem 1. If the ABox assertion set of an ontology A is complete, then any answer by O to a CQ is the same as answered by A.
Proof. Given a CQ, the pattern of the query falls into one of the three form as
Formula (
For a query in pattern of Formula (
For a query in pattern of Formula (
An algorithm is proposed to populate individuals to concept in A. In Algorithm 1, ABox assertion set and TBox axiom set are initialized on Line 1-2. The the loop in Line 3-10 computes all the necessary TBox axioms and explicitly adds them into T . Then the second loop in Line 11-24 compute the ABox assertions according to the computed T .
After population, A is complete. Each assertion in A could be coded into classical database record. Then the task to answer any CQ query is distributed to classical database queries. For the rest AQ, the task could be carried out with general purpose reasoners that support SWRL, which might be time-consuming, but acceptable for off-line administration. 7 8 9 10 RelBAC stands out of many other access control models for its rich expressiveness and formalism. Its logical complexity hinders its application in industry. We provide a framework to implement RelBAC in real-world software solutions. Queries that should be answered in run-time are distributed to classical database, that has complete ABox assertions coded into database records. Queries that could be answered off-line are distributed to DL reasoners with services of consistency checking, satisfiability checking, instance retrieval etc. With this combination in our framework, advantages of each query-answer mechanism could be taken and a practical implementation of RelBAC is foreseen.