Policy Elements

In this section we explore the notion of a policy and abstract it into a conceptual model. This section prepares us for going to the more detailed specification given in the next section. We start the design of the conceptual model with specification of the components that are to be modeled. At a conceptual level a policy is a compound entity, which regulates access to objects.

The notion of an object is central to the policy definition. An object is a target of requests and it has to be protected. An object can be a physical resource such as a host or a communication channel, as well as an abstract, higher level entity, e.g., a bank account.

An access right is a particular type of access to a protected object, e.g., read or write. The notion of a negative access right is useful to specify many practical policies. Sometimes it is easier to allow access to all and explicitly disallow access for those who should not have access.

A condition describes the context in which each access right is granted. A condition must be satisfied in order to allow an operation to be performed on a target object. Here are several of the more useful conditions [12].

• access identity

  Specifies an authenticated access identity (subject) on whose behalf request to access an object has been issued.

• time

  Time periods for which access is granted.

• location

  Location of the principal. Authorization is granted to the principals residing on specific hosts, domains, or networks.

• payment

  Specifies a currency and an amount that must be paid prior to accessing an object.

• quota

  Specifies a currency and a limit. It limits the quantity of a resource that can be consumed or obtained.

• audit

  Enables automatic generation of an application level audit data in response to access requests.

• notification

  Enables automatic generation of notification messages in response to access requests. Specifies the notification method and a receiver.

• trust constraints

  Specifies restrictions placed on security credentials. Allows one to validate the legitimacy of the received certificate chain and the authenticity of the specified keys.

• attributes of subjects

  Defines a set of attributes that must be possessed by subjects in order to get access to the object, e.g., user age.

Traditional security thinking has been oriented toward authentication as a prerequisite for authorization. Usually authorization applies after authenticated requester identity has been established.

In our model policies are treated as the first class citizens. Authentication, audit and accounting mechanisms are activated by explicit policy requirements, expressed through conditions. If a policy does not require authenticated user identity, authentication steps can be ignored or deferred until the policy explicitly requests it. An example of a policy, which is not concerned with the identity is ``anyone can read file 1#1 if $10 is paid''.

Note that in the implementation, some of these conditions might have side effects. For example, evaluation of payment and quota conditions reduces a balance somewhere. Evaluation of notification condition results in sending a message, which is useful in audit.

Unfortunately, side effects might complicate the model. Ignoring the side effects might cause problems when the side effects create a feedback loop, for example, when an audit record triggers a network threat detection which affects the evaluation of subsequent policies, or where payment affects quotas which affects the ability to perform other operations (once one runs out of money).

Balancing the complexity this adds with the simplicity of the model is still an open issue, which requires further investigation. Initial ideas on handling the side effects are given in Section .