The existing approaches to access control and usage control rely on three entities: subject, action and object. Hence specifying a security policy consists in specifying security rules applying on the {subject, action, object} triplet. It can be a permission for  some subject to realize some action on some object.
One of the main goals of the OrBAC model is to allow the policy designer to define a security policy independently of the implementation. The chosen method to fulfill this goal is the introduction of an abstract level where the role, activity and view concepts abstract the subject, action and object concepts.

A role is a set of subjects to which the same security rule apply. Similarly, an activity is a set of actions to which the same security rule apply and a view is a set of objects to which the same security rule apply. Each security policy is defined for and by an organization. A policy is confined in the organization which defines it. The following figure shows how those concepts are related:

This figure presents the main OrBAC concepts and their relationship

Abstract privileges can be specified using abstract entities. From these abstract privileges and the association between abstract and concrete entities, concrete privileges can be derived.

Actually the OrBAC model uses a first order logic formalism with negation. However, since first order logic is generally undecidable, we have restricted our model in order to be compatible with a stratified Datalog program. A stratified Datalog program can be evaluated in polynomial time. In the following we use a Prolog-like notation where terms beginning with an upper case are variables and terms beginning with a lower case are constants. The fact parent(john, jessica) says that john is a parent of jessica. A rule such as grandparent(X, Z) :- parent(X, Y), parent(Y, Z) means that X is a grandparent of Z if Y exists such that X is a parent of Y and Y is a parent of Z.

Using this formalism, each organization specifies its own security rules. Some role may have the permission, prohibition or obligation to do some activity on some view given an associated context is true. The context concept has been introduced in OrBAC in order to express dynamic rules. Those security rules are represented using 5-ary predicates:

  • permission(org, role, activity, view, context) means that in organization org, role role is authorized to perform activity activity on view view if context context is true
  • prohibition and obligation predicates are similarly defined but express different security requirements. The prohibition predicate states that a role is not authorized to perform some activity on some view when a given context is true. The obligation predicate means that some role must do some activity on some view when the associated context is true.

For example, the expression

permission(hospital, nurse, consult, medical_record, emergency)

means that nurses can access the patients medical records in the context of an emergency. Security rules can be hierarchically structured so that they are inherited in the organization, role, activity and view hierarchies. Since a security policy can be inconsistent because of conflicting security rules (for example a permission can be in conflict with a prohibition), it is necessary to define strategies to solve those conflicts.

Once the security policy has been specified at the organizational level, it is possible to instantiate it by assigning concrete entities to abstract entities. To do so, three ternary predicates have been defined to assign a subject to a role, an action to an activity and an object to a view:

  • empower(org, subject, role): specifies that in organization org, subject subject is empowered in role role
  • consider(org, action, activity): specifies that in organization org, action action implements activity activity
  • use(org, object, view): specifies that in organization org, object object is used in view view

For example, the fact empower(hospital, john, surgeon) states that john is empowered in the role surgeon in the hospital organization.

Contexts are defined through logical rules which express the condition that must be true in order for the context to be active. In the OrBAC model such rules have the predicate hold in their conclusion: hold(org, subject, action, object, context) specifies
that in organization org, subject subject does action action on object object in context context. Contexts can be combined in order to express conjunctive contexts, disjunctive contexts and context negation.

Using this model, concrete security rules applying to subject, actions and objects can be inferred as specified by the following derivation rule:

is_permitted(Subject, Action, Object) :-
    permission(Org, Role, Activity, View, Context),
   empower(Org, Subject, Role),
   consider(Org, Action, Activity),
   use(Org, Object, View),hold(Org, Subject, Action, Object, Context).

Similar rules are defined to infer the is_prohibited and is_obliged predicates which represent concrete prohibitions and concrete obligations.