52
Copyright © 2009 Open Geospatial Consortium, Inc.
The flexible matching of Subjects in the Target element supports direct association of access rights to subjects or roles, as defined in the RBAC profile of XACML [9]. In order
to derive an authorization decision for a given request, the XACML policy is traversed from the top i.e. PolicySet element to the leaves i.e. Rule elements. For all
matching Rule elements, their Effect i.e. Permit, Deny, etc. is taken as the most basic driver for the authorization decision. By traversing up the policy the effects of all Rules –
associated to a Policy element – are combined using the RuleCombiningAlgorithm. The resulting effects of all Policy elements are matched on the next highest level, until
reaching the top PolicySet element; the PolicyCombiningAlgorithm creates the final effect of the entire policy, which represents the authorization decision.
The XACML Policy Language defines four different results for the authorization decision: i Permit, ii Deny, iii Indeterminate and iv NotApplicable. Finally, the
process of deriving an authorization decision can result in an error, which is documented as additional information in the Decision element. In addition, the decision can be
“Permit with Obligation”, which can be expressed in the Obligation element, attached to the Policy or PolicySet element
Policies define permissions for subjects. Subjects are typically requestors and may be defined as individuals, user groups, applications, etc. Permission allows a subject to
perform a certain action on a certain resource.
12.2 XACML Data Flow Policy Model
OWS-6 used the XACML [8] policy models. The XACML specification allows defining conditions and obligations in addition to subject, resource, and action triples.
Cop
Figure 19, XACML v1.0 Data Flow Model
A resource may be a service, a layer of a WMS, a feature type of a WFS, a singe XML node of the service request or response, etc. Actions can be simply general access to a
resource, service operations such as GetMap or GetFeature, etc. It is part of the policy editor’s responsibility to express subjects, actions and resources for a given use case.
A policy is evaluated within the Policy Decision Point PDP. A Policy Enforcement Point PEP submits an XACML request context to the PDP, including information about
subject, resource, and action. Furthermore this XACML request context may include environment attributes, which may be evaluated by conditions.
It is necessary that the XACML request context corresponds to the policy model which shall be applied. If an XACML request context does not match to the subject, resource,
and action policies defined, a policy evaluation will fail. Therefore there is a logical
yright © 2009 Open Geospatial Consortium, Inc.
53
54
Copyright © 2009 Open Geospatial Consortium, Inc.
dependency between access decision request and the stored policy documents on the PDP.
If all applicable rules within the policy or the policy set evaluate to ‘permit’, then the PDP replies with a response context including a “Permit” statement. If the policy
evaluation leads to a denial, the PDP responds with a “Deny”. The message “NotApplicable” is returned if there is no policy which fits the XACML request context,
and errors during the policy evaluation lead to an “Indeterminate” response.
A PEP may only allow access as requested by the subject, if the PDP responds with a “Permit” which may include access restrictions using filtering capabilities of XACML
based on resource-id contained in the access decision response. All other responses have to result in a denial of access, due to the use of deny biased PEPs within this testbed.
12.3 Obligations
