The Ponder Policy Specification Language
`Nicodemos Damianou, Naranker Dulay, Emil Lupu, Morris Sloman
`Department of Computing, Imperial College, 180 Queen’s Gate, London SW7 2BZ
`{n.damianou, nd, e.c.lupu, m.sloman}@doc.ic.ac.uk
`
`Abstract
`
`The Ponder language provides a common means of
`specifying security policies that map onto various access
`control
`implementation mechanisms
`for
`firewalls,
`operating systems, databases and Java. It supports
`obligation policies that are event triggered condition-
`action rules for policy based management of networks
`and distributed systems. Ponder can also be used for
`security management activities such as registration of
`users or logging and auditing events for dealing with
`access to critical resources or security violations.
`Key concepts of the language include roles to group
`policies relating to a position in an organisation,
`relationships to define interactions between roles and
`management structures to define a configuration of roles
`and relationships pertaining to an organisational unit
`such as a department. These reusable composite policy
`specifications cater for the complexity of large enterprise
`information systems. Ponder is declarative, strongly-
`typed and object-oriented which makes the language
`flexible, extensible and adaptable to a wide range of
`management requirements.
`
`1. Introduction
`
`Large enterprise information infrastructures have to
`integrate inter-organisational networks and internet-based
`services, which makes the task of managing such systems
`very challenging. Distributed systems are changing from
`the traditional client-server model to a more dynamic
`service-oriented paradigm. The development of mobile
`computing applications requires support from adaptive
`network architectures and customised services to the
`clients. Various
`techniques
`have
`emerged
`for
`programming network elements to support adaptive
`services, for example active networks, mobile agents and
`management by delegation. While all these approaches
`support the programming of new functionality into
`network elements and host devices, they increase the
`security concerns regarding access to network resources
`and services, and make the management task even more
`demanding.
`Recent work on policy based management of
`networks
`and
`distributed
`systems
`(see www-
`dse.doc.ic.ac.uk/policies) provide promising solutions to
`these problems. In this work a policy is a rule that defines
`
`a choice in the behaviour of a system. Separating the
`policy from the implementation of a system permits the
`policy to be modified in order to dynamically change the
`strategy for managing the system and hence modify the
`behaviour of a system, without changing its underlying
`implementation [26].
`There are a number of groups working on very
`different approaches
`to specifying policy. Network
`component manufacturers and
`the IETF/DMTF are
`concentrating on
`information models
`[6][20] and
`condition-action rules with the focus on the management
`of Quality of Service (QoS) in networks [7][9][11][17].
`The security community have developed a number of
`models relating
`to specification of mandatory and
`discretionary access control policy [4]. This has evolved
`into work on role based access control (RBAC) [24] and
`role based management where a role may be considered
`as a group of related policies pertaining to a position in an
`organisation [15][16]. A lot of work within the greater
`scope of management has already resulted in architectures
`and technologies that provide the basic infrastructure
`required
`to
`implement policy-based management
`solutions [8][27].
`for policy-based
`Separate
`tools are emerging
`management of systems and specifying security. What is
`lacking is a common language that will provide a unified
`approach to supporting the concepts of the policy models
`emerging from the various research communities. We
`identify the following requirements for a policy language:
`(cid:120)(cid:3) Support for security policies for access control, and
`delegation to cater for temporary transfer of access
`rights to agents acting on behalf of a client as well as
`policies to express management activity.
`(cid:120)(cid:3) Structuring techniques to facilitate the specification of
`policies relating to large systems with millions of
`objects. This implies the need for policies relating to
`collections of objects rather than individual ones.
`(cid:120)(cid:3) Composite policies which allow the basic security and
`management
`policies
`relating
`to
`roles,
`to
`organisational units and to specific applications to be
`grouped. Composite policies are essential to cater for
`the complexity of policy administration in large
`enterprise information systems.
`It must be possible to analyse policies for conflicts
`and inconsistencies in the specification. In addition it
`should be possible to determine which policies apply
`
`(cid:120)(cid:3)
`
`V5 2/8/00
`
`1
`
`SAMSUNG 1045
`
`

`

`to an object or what objects a particular policy applies
`to. Declarative languages make such analysis easier.
`(cid:120)(cid:3) Extensibility is needed to cater for new types of policy
`that may arise in the future and this can be supported
`by inheritance in an object-oriented language.
`(cid:120)(cid:3) The language must be comprehensible and easy to use
`by policy users.
`This paper describes Ponder [5], a declarative, object-
`oriented
`language
`for
`specifying
`security
`and
`management policy for distributed object systems. The
`language is flexible, expressive and extensible to cover
`the wide range of requirements implied by the current
`distributed systems paradigms identified above. Ponder is
`the
`result of experience gained
`in policy-based
`management at Imperial College over the past 10 years
`[15][16][14][18][26]. We present the language syntax
`through simple examples of its use; for the complete
`syntax of the language see [6].
`Sections 2 and 3 present the basic policy types
`supported by Ponder. Constraints are described in section
`4. The composite policy structures
`in Ponder are
`described in section 5. Section 6 discusses features that
`make the language both flexible and extensible. In section
`7 we briefly compare Ponder with related work and
`section 8 presents conclusions and future work.
`
`2. Access Control Policies
`
`Access control is concerned with limiting the activity
`legitimate users who have been successfully
`of
`authenticated [1][23]. Our emphasis has been on
`discretionary access control, which can be modified by
`administrators or users and a subject with access
`permissions can pass them on to another subject. Ponder
`supports access control by providing authorisation,
`delegation, information filtering and refrain policies as
`described below.
`We assume that all policies relate to objects with
`interfaces defined in terms of methods using an interface
`definition language. We use the term subject to refer to
`users, principals or automated manager components,
`which have management
`responsibility. A subject
`accesses target objects (resources or service providers),
`by invoking methods visible on the target’s interface. The
`granularity of protection for access control in Ponder is
`thus an interface method. References to both subject and
`target objects are stored within domains maintained by a
`domain service. Domains provide a means of grouping
`objects to which policies apply and can be used to
`partition the objects in a large system according to
`geographical boundaries, object type, responsibility and
`authority or for the convenience of human managers [25].
`This
`facilitates policy specification
`for
`large-scale
`systems with millions of objects. Domains are similar to
`
`directories and have been implemented using an LDAP
`service.
`
`2.1. Authorisation Policies
`
`Authorisation policies define what activities a member
`of the subject domain can perform on the set of objects in
`the target domain. These are essentially access control
`policies,
`to protect
`resources and services
`from
`unauthorized access. A positive authorisation policy
`defines the actions that subjects are permitted to perform
`on
`target objects. A negative authorisation policy
`specifies the actions that subjects are forbidden to perform
`on target objects. Authorisation policies are implemented
`on the target host by an access control component.
`
`inst ( auth+ | auth– ) policyName “{”
`subject
`[<type>] domain-Scope-Expression ;
`
`target
`[<type>]
`domain-Scope-Expression ;
`
`action
`action-list ;
`
`
`
`[ when
`constraint-Expression ; ]
`
`
`
`
`“}“
`
`Figure 1. Authorisation Policy Syntax
`
`The syntax of an authorisation policy is shown in
`figure 1. In figure 1 and all subsequent figures presenting
`the syntax of the language, everything in bold is a token
`in the language. Choices are enclosed in ( and ) separated
`by |, optional elements are specified with square brackets
`[ ] and repetition is specified with braces { }. Constraints
`are optional in all types of policies and can be specified to
`limit the applicability of policies based on time or values
`of the attributes of the objects to which the policy refers.
`Constraints are discussed in detail in section 4. Elements
`of a policy can be specified in any order. Note that the
`subject and target elements can optionally include the
`interface specification reference within the specified
`domain-scope-expression on which the policy applies.
`This can be used to check that the objects do support the
`specified operations or
`to
`locate
`the
`interface
`specification. The name of a policy can specify the
`domain into which the policy could be stored.
`
`Example 1 Positive and negative authorisation policies
`
`inst auth+ switchPolicyOps {
`subject
`
`
`/NetworkAdmin ;
`action
`
`
`load(), remove(), enable(), disable() ;
`target <PolicyT>
`
`/Nregion/switches ;
`}
`
`
`Members of the NetworkAdmin domain are authorised to
`load, remove, enable or disable objects of type PolicyT in the
`Nregion/switches domain. This
`indicates
`the use of an
`authorisation policy to control access to stored policies.
`
`inst auth– /negativeAuth/testRouters {
`subject
`
`
`
`/testEngineers/trainee ;
`action
`
`
`
`performance_test() ;
`target <routerT> /routers ;
`
`}
`
`V5 2/8/00
`
`
`
`
`2
`
`
`
`

`

`
`
`Trainee test engineers are forbidden to perform performance
`tests on routers. The policy is stored within the /negativeAuth
`domain.
`
`
`The above examples show direct declaration of a
`policy instances using the keyword inst. The language
`provides reuse by supporting the definition of policy types
`to which any policy element can be passed as formal
`parameter. Multiple instances can then be created and
`tailored for the specific environment by passing actual
`parameters. Figure 2 shows the syntax for authorisation
`policy types and instantiations.
`
`type ( auth+ | auth– ) policyType “(” formalParameters “)” “{”
`
`{ authorisation-policy-parts }
`“}”
`
`inst ( auth+ | auth– ) policyName = policyType
`“(” actualParameters “)” ;
`
`Figure 2. Authorisation Types and Instantiations
`
`The authorisation policy switchPolicyOps
`(from
`example 1) can be specified as a type with the subject and
`target given as parameters as shown in example 2.
`
`Example 2 Declaring instances from types
`
`type auth+ PolicyOpsT (subject s, target <PolicyT> t) {
`
`
`action load(), remove(), enable(), disable() ;
`}
`
`inst auth+ switchPolicyOps =
`
`
`PolicyOpsT(/NetworkAdmins, /Nregion/switches) ;
`
`inst auth+ routersPolicyOps =
`
`
`PolicyOpsT(/QoSAdmins, /Nregion/routers) ;
`
`
`The two instance allows members of /NetworkAdmins and
`/QoSAdmins to execute the actions on policies within the
`/Nregion/switches and /Nregion/routers domains respectively.
`
`
`It can be argued that the specification of negative
`authorisation policies complicates the enforcement of
`authorisation in a system. However, there are reasons to
`support the provision for negative authorisation policies.
`Administrators often express high-level access control in
`terms of both positive and negative policies; retaining the
`natural way people express policies is important and
`provides greater
`flexibility. Negative authorisation
`policies can also be used to temporarily remove access
`rights from subjects if the need arises. In addition, many
`systems support negative access rights (e.g.Windows
`NT/2000).
`
`2.2. Information Filtering Policies
`
`the
`transform
`to
`Filtering policies are needed
`information input or output parameters in an action. For
`example, a location service might only permit access to
`detailed location information, such as a person is in a
`specific room, to users within the department. External
`
`users can only determine whether a person is at work or
`not. Some databases support similar concepts of ‘views’
`onto selective information within records – for example a
`payroll clerk is only permitted to read personnel records
`of employees below a particular grade. Positive
`authorisation policies may include filters to transform
`input or output parameters associated with their actions,
`based on attributes of the subject or target or on system
`parameters (e.g. time). In many cases it is not practical to
`provide different operations as a means of selecting the
`information. Although these are a form of authorisation
`policy they differ from the normal ones in that it is not
`possible for an external authorisation agent to make an
`access control decision based on whether or not an
`operation, specified at the interface to the target object, is
`permitted. Essentially the operation has to be performed
`and then a decision made on whether to allow results to
`be returned to the subject or whether the results need to be
`transformed. Filters can only be applied to positive
`authorisation actions.
`
`actionName { filter }
`
`filter = [ if condition ] “{”
`in parameterName = expression ;
`
`{
`(
` out parameterName = expression ;
`
`
`result = expression ;
`
`
`
`
`
`)
`
`
`}
`“}”
`
`|
`|
`
`Figure 3. Filters on Positive Authorisation Actions
`
`Every action can be associated with a number of filter
`expressions (see figure 3). Each filter contains an optional
`condition under which the filter is valid. If the condition
`evaluates to true, then the transformations (the assignment
`statements in the body of the filter) are executed. The
`in/out keywords are used to indicate input and output
`parameters of the action on which the filter is specified;
`result is used to transform the return value of the action.
`
`Example 3 Information filter policy
`
`inst auth+ filter1 {
`subject /Agroup + /Bgroup ;
`
`target USAStaff – NYgroup ;
`
`action VideoConf(BW, Priority)
`
`{ in BW=2 ; in Priority=3 ; } // default filter
`
`
`
`
`if (time.after("1900")) {in BW=3; in Priority = 1; }
`
`
`
`
`}
`
`
`Members of Agroup plus Bgroup can set up a video
`conference with USA staff except the New York group. If the time
`is later than 7:00pm then the video conference takes parameters:
`bandwidth = 3 Mb/s, priority = 1. Otherwise the first filter restricts
`the parameters to bandwidth = 2 Mb/s, priority = 3.
`
`2.3. Delegation Policies
`
`Delegation is often used in access control systems to
`cater for the temporary transfer of access rights. However
`
`V5 2/8/00
`
`
`
`
`3
`
`
`
`

`

`The above delegation policy accepts the switchPolicyOps
`auth+ policy from example 1 as a parameter. It states that the
`subject of that authorisation policy (NetworkAdmin), which is
`implicit in this policy, can delegate the enable and disable actions
`on policies from the domain /Nregion/switches/typeA to grantees
`in the domain /DomainAdmin. Note how the policy restricts the
`target to a subset of the switchPolicyOps policy target (See figure
`5). The valid-clause, specifies that the delegation is only valid for
`24 hours from the time of creation; after that it must be revoked.
`
` A
`
` delegation policy specifies the authority to delegate,
`it does not control the actual delegation and revocation of
`access rights. It is implemented as an authorisation policy
`that authorises the subject (grantor) to execute the method
`delegate on the run-time system with the grantee as the
`parameter of the method. At run-time, when the subject
`executes the delegate method, a separate authorisation
`policy is created by trusted components of the access
`control system, with the grantee as the subject. Similarly
`the revoke method deletes or disables that second
`authorisation policy.
`
`2.4. Refrain Policies
`
`Refrain policies define the actions that subjects must
`refrain from performing (must not perform) on target
`objects even though they may actually be permitted to
`perform the action. Refrain policies act as restraints on
`the actions that subjects perform and are implemented by
`subjects. Refrain policies have a similar syntax to
`negative authorisation policies, but are enforced by
`subjects rather than target access controllers. They are
`used for situations where negative authorisation policies
`are inappropriate – we do not trust the targets to enforce
`the policies (e.g. they may not wish to be protected from
`the subject). The syntax of refrain policies is the same as
`that of negative authorisation policies (figure 1).
`
`Example 5 Refrain Policy
`
`inst refrain testingRes {
`subject s=/test-engineers ;
`
`action
`
`discloseTestResults() ;
`target
`
`/analysts + /developers ;
` when
`s.testing_sequence = "in-progress" ;
`}
`
`
`This refrain policy specifies that test engineers must not
`disclose test results to analysts or developers when the testing
`sequence being performed by that subject is still in progress, i.e.,
`a constraint based on the state of subjects. Analysts and
`developers would probably not object to receiving the results and
`so this policy is not a good candidate for a negative authorisation.
`3. Obligation Policies
`
`Obligation policies specify the actions that must be
`performed by managers within the system when certain
`events occur and provide the ability to respond to
`changing
`circumstances.
`For
`example,
`security
`management policies specify what actions must be
`
`the ability of a user to delegate access rights to another
`must be tightly controlled by security policies. This
`requirement is critical in systems allowing cascaded
`delegation of access rights. A delegation policy permits
`subjects to grant privileges, which they possess (due to an
`existing authorisation policy, to grantees to perform an
`action on their behalf e.g. passing read rights to a printer
`spooler in order to print a file. A delegation policy is
`always associated with an authorisation policy, which
`specifies the access rights that can be delegated. Negative
`delegation policies forbid delegation. Note that delegation
`policies are not meant to be used for assignment of rights
`by security administrators.
`
`inst deleg+ “(”associated-auth-policy “)” policyName “{”
`grantee
`[<type>] domain-Scope-Expression ;
`
`[ subject
`[<type>] domain-Scope-Expression ; ]
`
`[ target [<type>]
`domain-Scope-Expression ; ]
`
`[ action
`action-list ; ]
`
`
`
`[ when
`constraint-Expression ; ]
`
`
`
`
`[ valid
`constraint-Expression ; ]
`
`
`
`
`“}”
`
`Figure 4. Delegation Policy Syntax
`
`Figure 4 shows the syntax of a positive delegation
`policy. Note that the only required part is the grantee.
`The rest of the parts (subject, target, action) must be
`subsets of those in the associated authorisation policy; if
`not specified they default to those of that policy. A
`positive delegation policy can specify delegation
`constraints to limit the validity of the delegated access
`rights, as part of the valid-clause. Such constraints can be
`time restrictions (duration, validity period) to specify the
`duration or the period over which the delegation should
`be valid before it is revoked. Note that negative
`delegation policies do not contain delegation constraints.
`
`
`
`
`auth+ switchPolicyOps
`
`NetworkAdmin
`
`load, remove,
`enable, disable
`
`deleg+ delegSwitchOps
`
`NRegion
`
`switches
`
`typeA
`
`DomainAdmin
`
`enable, disable
`
`Implicit auth+ policy
`Figure 5. Delegation and Authorisation Policies
`
`
`
`
`Example 4 Delegation policy
`
`inst deleg+ (switchPolicyOps) delegSwitchOps {
`grantee
`
`/DomainAdmin ;
`target
`/Nregion/switches/typeA ;
`
`action enable(), disable() ;
`
`valid
`
`
`time.duration(24) ;
`}
`
`
`V5 2/8/00
`
`
`
`
`4
`
`
`
`

`

`specified when security violations occur and who must
`execute those actions; what auditing and logging activities
`must be performed, when and by whom. Management
`policies could relate to management of QoS, storage
`systems, software configuration etc.
`Obligation policies are event-triggered and define the
`activities subjects
`(human or automated manager
`components) must perform on objects in the target
`domain. Events can be simple, i.e. an internal timer event,
`or an external event notified by monitoring service
`components e.g. a temperature exceeding a threshold or a
`component failing. Composite events can be specified
`using event composition operators.
`
`inst oblig policyName “{”
`
`on
`
`
`
`
`event-specification ;
`subject
`[<type>] domain-Scope-Expression ;
`
`[ target [<type>]
`domain-Scope-Expression ; ]
`
`do
`obligation-action-list ;
`
`
`
`
`
`[ catch
`
`
`
`exception-specification ; ]
`[ when
`constraint-Expression ; ]
`
`
`
`
`“}”
`
`Figure 6. Obligation Policy Syntax
`
` The syntax of obligation policies is shown in figure 6.
`Note the required event specification following the on
`keyword. The target element is optional as obligation
`actions may be internal to the subject or on a target,
`(whereas authorisation actions always relate to a target
`object). If actions are to be invoked on a target, then they
`must be preceded by a prefix indicating the target set.
`Concurrency operators specifying that actions should be
`executed sequentially or in parallel can separate the
`actions in an obligation policy. The optional catch-clause
`specifies an exception that is executed if the actions fail to
`execute for some reason.
`
`Example 6 Obligation policy
`
`inst oblig loginFailure {
`on
`
`
`
`
`3*loginfail(userid) ;
`subject
`
`
`s = /NRegion/SecAdmin ;
`target <userT>
`
`t = /NRegion/users ^ {userid} ;
`do
`
`
`
`t.disable() -> s.log(userid) ;
`}
`
`
`This policy is triggered by 3 consecutive loginfail events with
`the same userid. The NRegion security administrator (SecAdmin)
`disables the user with userid in the /NRegion/users domain and
`then logs the failed userid by means of a local operation
`performed in the SecAdmin object. The ‘->’ operator is used to
`separate a sequence of actions in an obligation policy. Names
`are assigned to both the subject and the target. They can then be
`reused within the policy. In this example we use them to prefix the
`actions in order to indicate whether the action is on the interface
`of the target or local to the subject.
`
`
`Types external to the policy specification can be
`specified assuming the corresponding specifications are
`accessible from a type repository.
`
`
`Example 7 External types
`
`type oblig printFail (string msg, QueueMan qMan) {
`on
`
`
`printfail(jobid, userid, filename);
`subject s = printManager;
`
`target ms = /servers/mailServer;
`
`do
`
` ms.mailto(userid, filename+msg) ||
`
`
`
`
`s.putInQueue(qMan, jobid);
` }
`
`
`The printFail obligation type accepts two parameters one of
`which is an external type called QueueMan. This is an interface
`specification of a printer queue manager object. The qman
`parameter is then used as a parameter in the call to putInQueue
`which is local to the printManager. The use of the || concurrency
`operator allows the actions to be performed in parallel.
`4. Constraints
`
`An important element of each policy is the set of
`conditions under which
`the policy
`is valid. This
`information must be explicit in the specification of the
`policy. The validity of a policy however, may depend on
`other policies existing or running in the system within the
`same scope or context. Those conditions are usually
`impossible or impractical to specify as part of each policy.
`We need to specify those as part of a group of policies. It
`is thus useful to divide the constraints in two categories:
`constraints for single policies and constraints for groups
`of policies, which we call meta policies. A subset of the
`Object Constraint Language (OCL) [22] is used to specify
`constraints in Ponder. OCL is simple to understand and
`use and it is declarative – each OCL expression is
`conceptually atomic and so the state of the objects in the
`system cannot change during evaluation.
`
`4.1. Basic Policy Constraints
`
`Basic policy constraints limit the applicability of a
`basic policy and are expressed in terms of a predicate,
`which must evaluate to true for the policy to apply. Policy
`constraints can be considered as conjunctions of basic
`constraints, which can be either time or state based
`constraints. The analysis of a set of policies can then be
`substantially improved since time-based constraints can
`be compared for possible overlap and state based
`constraints can be either simultaneously satisfied or
`mutually exclusive if they relate to states of the same
`system component. We separate the different types of
`constraints based on:
`(cid:120)(cid:3) Subject/target state – the constraint is based on the
`object state as reflected in terms of attributes at the
`object interface.
`(cid:120)(cid:3) Action/event parameters – constraints can be based on
`event parameter values in obligations or action
`parameter values in authorisations or refrains.
`
`V5 2/8/00
`
`
`
`
`5
`
`
`
`

`

`(cid:120)(cid:3) Time constraints specify the validity periods for the
`policy. A time library object is provided with Ponder
`to specify time constraints.
`The policy compiler can resolve the different types of
`constraints at compile time and separate the constraints in
`order to aid in the analysability of policies.
`
`Example 8 Use of attribute and time constraints
`
`inst auth- testRouters {
`subject s =/testEngineers;
`
`action
`
`performance_test();
` target /routers;
` when
`s.role = "trainee";
`}
`
`
`TestEngineers cannot execute performance tests on routers
`in they are trainee testEngineers. This role attribute of the subject
`is used in the constraint.
`
`inst auth+ filter1 {
`subject
`
`/Agroup + /Bgroup;
`target USAStaff – NYgroup
`
`action VideoConf(BW, Priority);
`
` when
`time.between("1600", "1800") ;
`}
`
`
`Members of Agroup plus Bgroup can set up a video
`conference with USA staff except the New York group. The time-
`based constraint limits the policy to apply between 4:00pm and
`6:00pm.
`
`4.2. Meta-Policies
`
`Meta-policies specify policies about the policies
`within a composite policy or some other scope, and are
`used to define application specific constraints. We specify
`meta policies for groups of policies, i.e. policies within a
`specific scope, to express constraints which limit the
`permitted policies
`in
`the system, or disallow
`the
`simultaneous execution of conflicting policies. A meta-
`policy is specified as a sequence of OCL expressions the
`last one of which must evaluate to true or false. The rest
`of the OCL expressions can be navigational expressions
`resulting in a collection. The raises-clause is followed by
`an action that is executed if the last OCL expression
`evaluates to true.
`
`inst meta metaPolName raises exception [ “(” parameters “)” ]
`“{”
`
`
`“}”
`
`{ OCL-expression}
`boolean-OCL-expression
`
`Figure 7. Meta-Policy Syntax
`
`The following examples indicate how meta-policies
`can be used to specify application dependent constraints
`on groups of policies.
`Self-Management: “There should be no policy
`authorising a manager to retract policies for which he is
`the subject”, from [12]. This happens within a single
`
`authorisation policy with overlapping subjects and targets.
`This can be specified in Ponder as follows:
`
`Example 9 Self-management meta-policy
`
`inst meta selfManagement1 raises selfMngmntConflict (pol) {
`
`[pol] = this.authorisations -> select (p | p.action->exists ( a |
`a.name = "retract" and a.parameter -> exists (p1 |
`
`
`p1.oclType.name = "policy" and
`
`
`
`
`
`
`
`p1.subject = p.subject))) ;
`
`
`}
`
`
`pol->notEmpty ;
`
`The body of the policy contains two OCL expressions. The
`first one operates on the authorisations set (part of the meta
`policy itself) of the meta policy (‘this” refers to the current object –
`in this case the meta policy), and selects all policies (p) with the
`following characteristics: the action set of p contains an action
`whose name is “retract”, and whose parameters include a policy
`object with the same subject as the subject of policy p. The
`second OCL expression is a boolean expression; it returns true if
`the pol variable, which is returned from the first OCL, expression
`is not empty. If the result of this last expression is true, the
`exception specified in the raises-clause executes. It receives the
`pol set with the conflicting policies as a parameter
`
`Example 10 Separation of duty
`
`inst meta budgetDutyConflict raises conflictInBudget(z) {
`
`[z] = self.policies -> select (pa, pb |
`pa.subject -> intersection (pb.subject)->notEmpty and
`
`
`and
`
`
`pa.action -> exists (act | act.name = “submit”)
`pb.action -> exists (act | act.name = “approve”) and
`
`
`
`
`pb.target -> intersection (pa.target)->oclIsKindOf (budget))
`
`
`
`z -> notEmpty ;
`}
`
`
`This metapolicy prevents a conflict of duty in which the same
`person both approves and submits a budget. It searches for
`policies with the same subject acting on a target budget in which
`there is an action submit and approve.
`
`The above policy implements a static separation of
`duties in that it prevents the same person being authorised
`to perform conflicting actions. Dynamic separation of
`duties is a slightly different, in that all members of a
`group are authorised to perform potentially conflicting
`actions but after performing one action they cannot
`perform a conflicting one. This is implemented as
`constraints relating to attributes of the subject and target
`object rather than as a meta-policy.
`
`Example 11 Dynamic separation of duty
`
`inst auth+ sepDuty {
`subject s = accountants ;
`
`action
`
`approvePayment, issue ;
`target
`
`t = cheques ;
` when
`s.id <> t.issuerID ; }
`
`
`The same user from the accountants domain cannot both
`issue and approve payment of the same cheque. This assumes
`that the identity of the issuer/approver can be stored as an
`attribute of the cheque object.
`
`V5 2/8/00
`
`
`
`
`6
`
`
`
`

`

`5. Composing Policy Specifications
`
`5.2. Roles
`
`policy
`facilitate
`policies
`composite
`Ponder
`management in large, complex enterprises. They provide
`the ability to group policies and structure them to reflect
`organisational structure, preserve the natural way system
`administrators operate or simply provide reusability of
`common definitions. This simplifies the task of policy
`administrators.
`
`5.1. Groups
`
`This is a packaging construct to group related policies
`together for the purposes of policy organisation and
`reusability and
`is a common concept
`in most
`programming
`languages. There are many different
`potential criteria for grouping policies together – they
`may reference the same targets, relate to the same
`department or apply to the same application. Figure 8
`shows the syntax for a group instance. It can contain zero
`or more basic policies, nested groups and/or meta-policies
`in any order. A meta-policy specifies constraints on the
`policies within the scope of the group.
`
`inst group groupName “{”
`
`{ basic-policy-definition }
`
`{ group-definition }
`
`{ meta-policy-definition }
`“}”
`
`Figure 8. Group Syntax
`
`Reusability can be achieved by specifying groups as
`types, parameterised with any policy element and then
`instantiating them multiple times. For instance, policies
`related to the login process can be grouped together since
`they must always be instantiated together (example 12).
`
`Example 12 Group policy
`
`inst group loginGroup {
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`}
`
`
`
`
`inst auth+ staffLoginAuth {
`subject
`
`/dept/users/staff ;
`target
`
`/dept/computers/research;
`action
`
`login;
`}
`
`inst oblig loginactions {
`subject
`
`s = /dept/c