SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 110 of 233
Figure 7-5: Basic SAML concepts OASIS 2006b
In SensorSA SAML core assertions and protocol is used exclusively or in other words no bindings or profiles have been defined. The use of SAML in the context of the access control
services is further described in section 10.5.4.
7.4.6.2 XACML eXtensible Access Control Markup Language
―XACML is language for expressing access control policies. The language is used to standardise the process of access control management. Access control management consists of some or all of
the following steps: writing, reviewing, testing, approving, issuing, combining, analysing,
modifying, withdrawing, retrieving and enforcing of policies‖ OASIS 2005. XACML delivers a language to encapsulate security rules in policies in a standardised manner. If the same
mechanisms of access control are used throughout the components of an information infrastructure, it is possible to manage the enforcement of policies in a consistent and to some
extent interoperable way. In the SensorSA XACML and extensions like GeoXACML can be used as a common access control language.
The following paragraph describes XACML‟s basic elements and establishes a connection between the concepts described in section 7.4 and XACML. Furthermore, it provides an
overview of the GeoXACML extensions.
7.4.6.2.1. XACML Basic Concepts The following paragraphs are slightly modified extractions from the eXtensible Access
Control Markup Language XACML standard OASIS 2005 intended to give an overview of the XACML components and principles.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 111 of 233
-
Rule A rule is the most elementary unit of a policy. A rule can be evaluated on the basis of its
contents and the request. The main components of a rule are a target, an effect and a condition.
-
Rule target The target defines the set of resources, subjects, actions and environment to which the
rule is intended to apply it is possible to further refine the applicability by the target with conditions see OASIS 2005. An XACML PDP verifies that the matches defined by the
target are satisfied by the subject, resource, action and environment attributes in the request context, e.g. role. In summary, targets are used to determine which rules match
the given request.
Where subjects and their attributes are used to encode the identities and related attributes like‟ role‟ described in section 7.4.4 .
-
Effect The effect of a rule indicates the rule-writers intended consequence of a True
evaluation for this particular rule. Two values are allowed: Permit and Deny.
-
Policy A policy is a container for rules and other information, e.g. a general policy target or a
particular rule combining algorithm to support different matching policies for an authorisation request.
-
PDP functionality After receiving a request the PDP matches the request against the policies to determine
the policies to be considered, where matching simply means the evaluation of the target, which comprises functions on the attributes of the elements subject, resource, action and
environment as described in the paragraph Rule. In case one of the targets matches, the
effect is either “Permit” or “Deny”. It is possible that there is more than one matching rule, in this case the defined combining algorithm is used to provide an authorisation
decision, e.g. if the combining algorithm is “Deny-overrides” then one occurrence of a
“Deny” overwrites all occurrences of “Permit”.
7.4.6.2.2. GeoXACML: The geospatial extension of XACML Geospatial eXtensible Access Control Markup Language GeoXACML is an OGC
Implementatio n Standard and “defines an extension to XACML for spatial data types and spatial
authorisation decision functions. Those data types and functions can be used to define additional spatial constraints for XACML based policies.” OGC 07-026r2
It makes use of existing XACML extension points to be fully compatible to the XACML standard. This means that a “GeoPDP” is not only able to evaluate GeoXACML decision queries
but standard XACML queries as well.
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 112 of 233
―GeoXACML extends XACML by only one new data type that is named ―urn:ogc:def:dataType:geoxacml:1.0:geometry‖.‖ OGC 07-026r2 It contains geometric data
types described in OGC 06-103r3. There are also two extensions to the GeoXACML implementation specification that define GML encoding for GML version 2 OGC 07-098r1
and 3 OGC 07-099r1.
The XACML extension point for data types is illustrated in the XML fragment. As the DataType attribute is of type anyURI the additional geometry data type can be used.
Figure 7-5: AttributeValue extension point of XACML
Figure 7-6: AttributeDesignatorType extension point of XACML
Figure 7-7: AttributeSelectorType extension point of XACML
There are 34 new functions of two different conformance classes defined by GeoXACML, nineteen functions of conformance class BASIC and fifteen of conformance class STANDARD.
The different functions cover several aspects of geographic evaluation:
-
Topological functions conformance class BASIC
-
Bag functions conformance class BASIC
-
Set functions conformance class BASIC
SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1
Copyright © 2007-2009 SANY Consortium Page 113 of 233
-
Geometric functions conformance class STANDARD
-
Conversion functions conformance class BASIC A “GeoPDP” has to implement all functions of conformance class BASIC to be considered
a BASIC GeoXACML conformant PDP implementation. A STANDARD conformant PDP implementation has to implement all functions of conformance class STANDARD in addition to
all functions of conformance class BASIC.
The XACML extension point for function types is shown in the following figure. As the FunctionId attribute is of type anyURI any additional function may simply be used. GeoXACML
does not define any additional or changed XSD schema elements to XACML to stay XACML conformant.
Figure 7-8: Function type extension point of XACML
7.5. Event Information Model
