2.2.2 Authorisation and Obligation Policies

The concept of policies was further developed and in [MoSl 91] policies were not only understood as rules for access control. In that paper, policies are intended to influence actions. Operations or actions are always characterised by a motivation and need authorisation to be performed.

Figure: Precondition for an action [Slom 94a]

Figure  shows the precondition saying that both motivation and authorisation are necessary before an operation can take place. Although they share the same precondition, motivation and authorisation are seen independently of each other. Other facts shown in figure  are that motivation and authorisation must have the same subject, (i.e., AgentA) which performs the operation. Also, it must have the same target (i.e., ObjectB), which is affected by the operation. As a requirement, motivation and authorisation must be stated for the same operation, i.e. OpX.

Table 2.1: Structure of a policy [SlLu 98]

The general format of a policy is displayed in figure . Optional attributes are within brackets. The braces and the semicolon are semantic separators. Some attributes such as trigger, subject, action, target, and constraint may be comments, in which case the policy is considered a high-level policy and it is not possible to interpret it directly. It is made up by the following attributes:

identifier

is the name of the policy.

mode

To support the different characteristics of motivation and authorisation, a mandatory modality attribute was introduced. In recent publications the term obligation is used instead of motivation. Four policy modalities are possible distinguishing between positive and negative authorisation/obligation policies.

Authorisation Policies

specify which actions a subject is permitted or prohibited to perform on a set of target objects, or which pieces of information that are being monitored can be received. Therefore, there are positive (A$+$) and negative (A$-$) forms of authorisation policies. The positive form states that an activity is allowed and the negative one states that an activity is prohibited. To perform an action, explicit authorisation is necessary, which means that non-authorised invocations are forbidden by default.

Obligation Policies

specify, given a set of target objects, what activities a subject, i.e. a person or an agent, must perform in case of the positive form (O$+$), or must not in case of the negative form (O$-$). trigger events start the enforcement of positive obligation policies.

subject

This attribute defines to whom the policy applies, i.e. which objects^2.2 are authorised or obligated (responsible) to carry out the policy goal within the limits defined by the policy constraints. Subjects are usually expressed as a domain of objects and a policy applies to all objects in that domain. Authorisation policies can have a domain expression of any (see figure ) as subject.

action

or policy goal, which is modelled by operations, specifies what must be performed in case of obligation policies and what is permitted in case of authorisation policies. Multiple actions can also be specified.

target

specifies the objects on which the policy actions are to be performed. They are expressed with the help of domain scope expressions of objects. A policy applies to all objects specified by the domain scope expression.

constraint

limits the applicability of a policy, e.g. to a particular time period, or makes it valid after a particular date. It must be evaluated and fulfilled before a policy is to have any effect.

exception

attribute specifies alternative actions and is only allowed in the case of a positive obligation policy. With a failure of a positive obligation policy, the alternative actions are executed.

parent and child

are added automatically as part of the refinement process to create a policy hierarchy.

xref

is a manually included cross reference list to additionally reference other policies, e.g. authorisation policies that grant permission for an obligation policy.

Table 2.2: Domain scope expressions [Marr 97]

Table 2.3: Authorisation and obligation policy examples [SlLu 98]

Table  lists the domain scope expression operators and table  shows some policy examples. Policies are modelled as system objects and there is a minimal set of operations defined, i.e. create, destroy, and query.

Negative authorisation policies and negative obligation policies are not semantically equivalent. Obligation policies are always interpreted by subjects, whereas authorisation policies are used by the target's support system to specify access rights.