1. Access Control for OGC Web Services with (Geo)XACML
69th OGC Technical Committee Meeting
Massachusetts Institute of Technology
Cambridge, USA
June 23, 2009
Jan Herrmann
Technische Universität München
Department of Informatics
Chair for Applied Informatics / Cooperative Systems

2. Overview Background information
access control requirements in Spatial Data Infrastructures
access control system architecture and workflow
How to represent OWS specific information in a XACML decision request?
How to write access control rules referring to the OWS specific information?
Evaluation of pre- and post-processing access control in the OWS context
At the beginning I will provide you with some background information
and summarize the requirements we have towards an access control system in SDIs.
Additionally I will show how such an ACS looks like and explain the workflow during the access control process..
As the topics Access Control for OGC Web Services is a huge subject area,
I can only address three interesting issues in this presentation:
First I will try to give answers to the question how to represent OWS specific information in XACML a.c.d.r.?
Then I will introduce the different mechanisms how to write rules referring to the OWS data representations in a.c.d.r.
At the end I will briefly highlight the characteristics of pre and post-processing access control for OWS and compare the pros and cons of each of the approaches.

3. Access Control Requirements in Spatial Data Infrastructures
declaration of:
fine-grained, positive and negative access rules
content dependent access rules
spatial access rules
context dependent access rules
Background Information

4. Example 1: Declaration of Fine-Grained Access Rules
<features>
<building classification="secret">
<owner>
<name>
<first>Bob</first>
<last>Meyer</last>
</name>
<gender>male</gender>
</owner>
<price> </price>
<location>
<gml:Polygon srsName="epsg:31467">
<gml:outerBoundaryIs>
<gml:LinearRing>
<gml:coordinates> , </gml:coordinates>
</gml:LinearRing>
</gml:outerBoundaryIs>
</gml:Polygon>
</location>
</building>
</features>
XML attribute node based restriction e.g. (-, Alice, read,
XML element node based permission e.g. (+, Alice, read, /Building/owner)
XML element node based restriction e.g. (-, Alice, read, /Building/Price)
Background Information

5. Example 2: Declaration of a Content Dependent Rule
<features>
<building classification="secret">
<owner>
<name>
<first>Bob</first>
<last>Meyer</last>
</name>
<gender>male</gender>
</owner>
<price> </price>
<location>
<gml:Polygon srsName="epsg:31467">
<gml:outerBoundaryIs>
<gml:LinearRing>
<gml:coordinates> , </gml:coordinates>
</gml:LinearRing>
</gml:outerBoundaryIs>
</gml:Polygon>
</location>
</building>
</features>
content dependent permission e.g. (+, Alice, read, /Building, if /Building/price/text() < 2,000,000 $)
Background Information

6. Example 3: Declaration of a Spatial Access Control Rule
<features>
<building classification="secret">
<owner>
<name>
<first>Bob</first>
<last>Meyer</last>
</name>
<gender>male</gender>
</owner>
<price> </price>
<location>
<gml:Polygon srsName="epsg:31467">
<gml:outerBoundaryIs>
<gml:LinearRing>
<gml:coordinates> , </gml:coordinates>
</gml:LinearRing>
</gml:outerBoundaryIs>
</gml:Polygon>
</location>
</building>
</features>
spatial permission e.g. (+, Alice, read, /Building, if /Building/location/Polygon within USA)
Background Information

7. Example 4: Declaration of a Context Dependent Rule
Resource:
<features>
<building>
....
<location>...</location>
</building>
</features>
Access Control System Context:
<acs-context>
<current-time>10 am</current-time>
<disaster-location>
<gml:Point srsDimension="2" srsName="urn:ogc:def:crs:EPSG:6.6:4326">
<gml:pos> </gml:pos>
</gml:Point>
</disaster-location>
...
XML element node based context dependent permission e.g. (+, Alice, read, /Building, if current-time between 8am-6pm and
distance(/Building/location, /acs-context/disaster-location) < 500 meter)
Background Information

8. Access Control Requirements in Spatial Data Infrastructures
declaration of:
fine grained, positive and negative access rules
content dependent access rules
spatial access rules
context dependent access rules
pre- & post-processing access control
filtering
access control system based on standards
WS request
Geodata Repositories
Web Service
pre-processing access control
WS response
post-processing access control
Background Information

9. Architecture of a Rule based Access Control System1
users
WFS-T
WS-Request/Response
WS-Request/Response
PEP
(WS)
security assertion (e.g. authent. data)
security assertion (e.g. authent. data) 3
XACML Access Control Decision Request
XACML Access Control Decision Response(s) 2
Geodata Repositories
PDP
(WS)
Authentication Service
Authentication Service
Authentication Service
Authentication Service
Authentication Service
WMS
PAP (WS)
WPS
(Geo)XACML Rule Repository 4
Administrators
Background Information

10. How to represent OWS specific information in XACML decision requests?
Option 1:
XACML Attribute/AttributeDesignator approach
Option 2:
XACML ResourceContent/AttributeSelector approach
Representation of OWS data in decision requests

11. Representation of OWS specific information in a XACML decision request
Option 1: XACML Attribute/AttributeDesignator approach
information about OWS requests or OWS responses is represented as XACML Attributes in a XACML decision request
Problems: XACML Attributes...
destroy the hierarchical structure and the semantical relationships that exist in the OWS request or response data
imply more generalized i.e. coarse-grained atomic information entities
Representation of OWS data in decision requests

12. Example
you loose the relationships between nodes
you generate generalized i.e. coarse-grained atomic information entities  loss of referencable information
avoidable only through generation of attributes for each possible subset (c.p. srs)
 
Attributes destroy the hierarchical structure & semantical relationships and imply more generalized i.e. coarse-grained atomic information entities
XACML Attributes
<wfs:FeatureCollection ...>
<gml:featureMember>
<Building>
<Owner>alice</Owner>
<Price> </Price>
<Location>
</Location>
</gml:featureMember>
<Owner>bob</Owner>
<Price>500000</Price>
<!--... more features >
</wfs:FeatureCollection>
AttributeName
AttributeValue
urn:???:owner
alice
urn:???:owner
bob
urn:???:price
urn:???:price
500000
urn:???:polygon
...
urn:???:srs
urn:...wgs84
...
...
Representation of OWS data in decision requests

13. Representation of OWS specific information in a XACML decision request
Option 1: XACML Attribute/AttributeDesignator approach
information about OWS requests or OWS responses is represented as XACML Attributes in a XACML decision request
Problems:
XACML Attributes...
destroy the hierarchical structure and the semantical relationships in the OWS request or response data
imply more generalized i.e. coarse-grained atomic information entities
 XACML Attributes are only useful if the information is atomic without structural relation
lots of URNs for attribute-names & -values have to be defined for unique identification (e.g. action-id = { getMap, getFeature, transaction, insert, update, delete...})
Representation of OWS data in decision requests

14. Representation of OWS specific information in a XACML decision request
Option 1: XACML Attribute/AttributeDesignator approach
information about OWS requests or OWS responses is represented as XACML Attributes in a XACML decision request
Conclusion Attribute/AttributeDesignator approach:
not powerful enough as arbitrary WS requests and responses can not be easily, completely transformed into appropriate XACML Attributes without reducing the possible authorization semantics
 XACML Attributes are not suitable for the representation of OWS
specific information in access control decision requests.
Representation of OWS data in decision requests

15. Representation of OWS specific information in a XACML decision request
Option 2: XACML ResourceContent/AttributeSelector approach
information about OWS requests or OWS responses is represented under the XACML <ResourceContent> element only
Pros:
flexible and powerful solution
arbitrary information (i.e. node sets) under the ResourceContent element can be selected & serve as input for functions in XACML rules
easy solution
no URN definitions necessary (the standardized OGC XML schemas for OWS achieve uniqueness)
no attribute instantiation is necessary inside the PEP
Interim Conclusion:
use the ResourceContent/AttributeSelector approach to represent OWS specific information in a XACML decision request
Representation of OWS data in decision requests

16. The KVP Problem
XML encoded WS request  access control decision request 
KVP encoded WS request  access control decision request ?
Options:
KVP encoded WS request  XACML Attributes not advisable 
as shown...
XACML Attributes are not powerful enough because arbitrary WS requests and responses can’t be easily, completely transformed into appropriate XACML Attributes without reducing the possible authorization semantics
many URNs have to be defined
KVP encoded WS request  XML encoded WS request  a.c.d.r. 
Representation of OWS data in decision requests

17. The KVP Problem Solution:
KVP encoded request  XML encoded WS request  a.c.d.r.
Consequence:
We need unique and standardized guidelines how to transform
KVP encoded OWS requests into an XML encoded OWS requests
Key Questions:
does every OWS spec that defines a KVP request encoding also defines a normative XML Schema for its requests?
if so, is the transformation of OWS requests from KVP encoding to XML encoding a unique projection?
YES (except WMS)
Representation of OWS data in decision requests

18. Representation of OWS specific information in a XACML decision request
Option 1:
XACML Attribute/AttributeDesignator approach
Option 2:
XACML ResourceContent/AttributeSelector approach
Conclusion:
always use Option 2 to represent OWS data in decision requests
in case of KVP encoded requests transform to XML before adding OWS data to the XACML decision request
(Notitz: nicht vergessen zu erwähnen, dass dadurch ein regelwerk möglich ist egal ob kvp oder xml encoded requst)
Representation of OWS data in decision requests

19. How to write rules referring to OWS specific information in a XACML decision request?
Option 1: using the AttributeSelector mechanism
Option 2: using the XACML Multiple and Hierarchical resource
profile based mechanism
Option 3: using the XPath-node-match mechanism
Writing rules referring to OWS data in decision requests

20. The AttributeSelector mechanism in the OWS context
Intended authorization semantic:
Alice is not allowed to read Building data if the building’s price is above 500,000 $
XACML Rule (highly simplified):
<Rule Effect="Deny">
AttributeDesignator(subject-id) = "Alice" and
AttributeSelector(“count(/ResourceContent/FeatureCollection/
featureMember[building/price>" "])") > 0
</Rule>
WFS response in the a.c.d.r:
<FeatureCollection>
<featureMember>
<building>
<owner>...</owner>
<price>1,000,000</price>
<location>...</location>
</building>
<price>300,000</price>
</featureMember>
...
Writing rules referring to OWS data in decision requests

21. Evaluation of the AttributeSelector mechanism
only predicates supported by XPath can be used to define content dependant authorizations limited expressiveness
no pointers to XACML decision request data inside an XPath predicate (e.g. permit access if /bulding[owner = subject-id]) limited expressiveness
filtering is not possible
the XACML decision response refers to the Web Service request or response as a whole
??soll ich die erweiterung vorstellen??? Hebelt im prinzip xacml ziemlich as. Effekt der regel wird egal...was wenn mehrere regeln greifen?obligation-kombining wird notwendig..
Writing rules referring to OWS data in decision requests

22. The XACML Multiple and Hierarchical Resource Profile based mechanism in the OWS context
global access control decision request
...
resource-id = /ResourceContent[1]/wfs:FeatureCollection[1]
scope = descendants (or children or immediate)
derived individual access control decision requests
resource-id = /ResourceContent[1]/FeatureCollection[1]
scope = descendants
definition of a matching rule:
<Rule Effect="Deny"> ...reg-expr-string-match(resource-id, /ResourceContent\[\d+\]/FeatureCollection\[\d+\]/FeatureMember\[\d+\]) and AttributeSelector(resource-id+"/Building/Price") > 500,000 …
/ResourceContent[1]/FeatureCollection[1]/FeatureMember[1]
/ResourceContent[1]/FeatureCollection[1]/FeatureMember[1]/Building[1]
/ResourceContent[1]/FeatureCollection[1]/FeatureMember[1]/Building[1]/owner[1]
/ResourceContent[1]/FeatureCollection[1]/FeatureMember[1]/Building[1]/price[1]
/ResourceContent[1]/FeatureCollection[1]/FeatureMember[1]/Building[1]/location[1]
/ResourceContent[1]/FeatureCollection[1]/FeatureMember[2]
Writing rules referring to OWS data in decision requests

23. Evaluation of the mechanism based on the XACML multiple and hierarchical resource profile
more expressive than the AttributeSelector mechanism
all XACML and GeoXACML functions can be used to define content dependant authorizations
flexible use of pointers to data in decision requests
filtering is possible
each a.c. decision response has a resource-id attribute and PEPs can use the resource-id values to filter out the access restricted nodes (e.g. by XSLT)
Side note on performance:
implementation dependant  can be as fast as the AttributeSelector mechanism
behavior described just shows the mechanism
performance optimized processing is allowed as long as the results are the same
Writing rules referring to OWS data in decision requests

24. The XPath-node-match mechanism in the OWS context
xpath-node-match(XPath_Expr1, XPath_Expr2)
Evaluates to true if
Any of the XML nodes in the node-set matched by the first argument is equal to any of the XML nodes in the node-set matched by the second argument, or
if any attribute and element node below any of the XML nodes in the node-set matched by the first argument is equal to any of the XML nodes in the node-set matched by the second argument
Example:
expr1: resource-id= /ResourceContent/FeatureCollection
expr2: rule XPath /ResourceContent/FeatureCollection/FeatureMember/Building/price
 XPath-node-match(expr1, expr2) evaluates to true if there is a price element in the WFS Response
Writing rules referring to OWS data in decision requests

25. Evaluation of the XPath-node-match mechanism
same limitations like the AttributeSelector mechanism
only predicates supported by XPath can be used to define content dependant authorizations limited expressiveness
no pointers to XACML decision request data inside an XPath predicate (e.g. permit access if /bulding[owner = subject-id]) limited expressiveness
filtering is not possible
the XACML decision response refers to the Web Service request or response as a whole
Writing rules referring to OWS data in decision requests

26. Mechanisms for writing rules referring to OWS request or response information in the decision request
spatial or arbitrary functions & predicates
flexible use of pointers
filtering
AttributeSelector no
Mult. and Hierarch. Resource Profile based
yes
XPath-node-match
Conclusion:
Option 2 is the most expressive mechanism
depending on your requirements option 1 and 3 could also
be used
Writing rules referring to OWS data in decision requests

27. Evaluation: Post-processing access control for OWS
Advantages:
complex authorizations can be enforced
ACS is last entity before data gets submitted to the user
Disadvantages:
data relevant for deriving the access control decision can be missing because it was not requested by the user
Solutions:
base access control rules only on mandatory schema elements only limited expressiveness 
PDP/PIP mechanism to request extra data needed during rule evaluation
processing overhead possible
Pre-processing vs. Post-processing in the OWS context

28. Pre-processing access control for OWS with (Geo)XACML
the same mechanisms like for post-processing are available
WFS request:
<GetFeature>
<Query typeName="Building">
<PropertyName>owner</PropertyName>
<PropertyName>price</PropertyName>
<PropertyName>location</PropertyName>
<ogc:Filter> ... </ogc:Filter>
</Query>
</GetFeature>
Problem: limitations when expressing content dependent
pre-processing authorization semantics
betonen dass es wieder nen xml dik ist und daher das selbe wie beim bost proc geht.
der einzoge unterschied: sematischer unterschdied der datan. jetzt anfragen!
bsps zeigen wie man
regeln kann was wer selektieren kann
und b) wie man selektieren kann
betonen
dass man keine aussagekräftigen regeln basierend auf dem filter element schreiben kann
daher limitations defining inhaltsabhängige regeln
was so geht und was nicht.. betonung dass man später sagen was nur dank obligations geht (what can be done directly,when and how to use obligations)
Pre-processing vs. Post-processing in the OWS context

29. Pre-processing access control for OWS with (Geo)XACML
Filter extension approach
allowing for more expressive content dependant pre-processing access control rules
Example:
WFS request: getFeature(Building, {Owner, Price, location}, Filter: Owner=State)
Rule: (+, Alice, Building) & Obligation: Price > 500,000
WFS request after AC/query rewriting:
getFeature(Building, {Owner, Price, location}, Filter: Owner=State and Price > 500,000)
Pre-processing vs. Post-processing in the OWS context

30. Evaluation: Pre-processing access control for OWS
Advantages:
fine-grained, content dependant... AC for OWS operations without structured response (e.g.:
WMS: image as response
WFS: insert, update, delete operations)
avoiding the problems of the post-processing approach
data for rule evaluation is missing
processing overheads
Disadvantages:
security leakage in case of
processing error in service
unexpected Service behavior (e.g. WFS adding mandatory properties according to xsd)
reduced expressiveness
the enforceable rights are dependent on the capabilities of the Web Service request language
Pre-processing vs. Post-processing in the OWS context

31. Reduced expressiveness of the pre-processing approach because of WS request language dependency
Example:
intended rule semantic
(+, Alice, /Building)
(-, Alice, /Building/price, if Price >500,000)
WFS request: getFeature(Building, {Owner, Price, location}, Filter: Owner=State)
How to define the obligation?
Obligation: Price > 500,000
getFeature(Building, {Owner, Price, location}, Filter: Owner=State and Price > 500,000) 
Problem: WFS request language does only allow filters on FeatureTypes and doesn’t allow filters on properties.
Pre-processing vs. Post-processing in the OWS context

32. Summary: Pre- and Post-processing Access Control for OWS
pre- as well as post-processing has its advantages and disadvantages
the right solution depends on:
the type of services and operations you are trying to protect
the needed types of authorization semantics
if filtering is needed
a hybrid approach might leverage the advantages of both concepts

33. thank you very much for your attention questions, comments, ...?
Jan Herrmann
Technische Universität München

37. appearance of spatial data KVP/Attributes files (e.g. XML/GML)
Baseline
appearance of spatial data
KVP/Attributes
files (e.g. XML/GML)
spatial data bases
(O)WS-requests and –responses
</gml:pos> </gml:Point>

38. Starting point when defining access control rules
Read File Scenario
Resource: XML/GML file + .xsd
Authentication Data
<features>
<building classification="secret">
<owner>
<name>
<first>Bob</first>
<last>Meyer</last>
</name>
<gender>male</gender>
</owner>
<price> </price>
<location>
<gml:Polygon srsName="epsg:31467">
<gml:outerBoundaryIs>
<gml:LinearRing>
<gml:coordinates>....</gml:coordinates>
</gml:LinearRing>
</gml:outerBoundaryIs>
</gml:Polygon>
</location>
</building>
</features>
<authenticationData>
<subject>
<name>Alice</name>
<role>student</student>
</subject>
<authenticationMethod>Username/Password</...>
...
Access Control System
Access Control System Context
<acs-context>
<current-time>10 am</current-time>
<disaster-location>
<gml:Point>... </gml:Point>
</disaster-location>
...

39. Starting point when defining access control rules
Web Service Scenario
WS request
XML or KVP
Web Service
PEP
Authentication Data
XML or KVP
XML or unstructured
WS response
Geodata Repositories
PDP
XML or KVP
Access Control System Context
(Geo)XACML Rule Repository

40. Notitz zu mult/hier/mein Ansatz:
immer möglichst tief regel ansetzen lassen.(prob multipler knoten unter abschnittpunkt)
will man weiter oben abschneiden dann per resource-id/../..

41. Evaluation of the AttributeSelector mechanism
only predicates supported by XPath can be used to define content dependant authorizations limited expressiveness
no pointers to XACML decision request data inside an XPath predicate (e.g. permit access if /bulding[owner = subject-id]) limited expressiveness
filtering is not possible
 solvable through special obligations: e.g.
<nodesToFilter> <getUniqueXPath> /ResourceContent/FeatureCollection/featureMember[building/price>“ "])
</getUniqueXPath>
</nodesToFilter>
??soll ich die erweiterung vorstellen??? Hebelt im prinzip xacml ziemlich as. Effekt der regel wird egal...was wenn mehrere regeln greifen?obligation-kombining wird notwendig..
Writing rules referring to OWS data in decision requests

42. Mechanisms for writing rules referring to OWS request or response information in the decision request
spatial or arbitrary functions & predicates
flexible use of pointers
filtering
AttributeSelector no
+ Obligations
yes
Mult. and Hierarch. Resource Profile based
XPath-node-match
Writing rules referring to OWS data in decision requests

44. The structure of XACML related standards & profiles
OGC Web Service Profile of GeoXACML
...
SAML Profile of XACML
RBAC Profile of XACML
Multiple Resource Profile of XACML
Hierarchical Resource Profile of XACML
GeoXACML
XACML Core Specification