Access Control for OGC Web Services with (Geo)XACML
modified version of the presentation given at the 69th OGC Technical Committee Meeting
at the Massachusetts Institute of TechnologyCambridge, USA
June 23, 2009
Technische Universität MünchenDepartment of Informatics
Chair for Applied Informatics / Cooperative Systems
2/32
Overview
1. Background information– access control requirements in Spatial Data
Infrastructures– access control system architecture and workflow
2. How to represent OWS specific information in a XACML decision request?
3. How to write access control rules referring to the OWS specific information?
4. Evaluation of pre- and post-processing access control in the OWS context
5. Important Change Requests for XACML 3.0 and profiles
3/32
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/32
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>1000000</price> <location> <gml:Polygon srsName="epsg:31467"> <gml:outerBoundaryIs> <gml:LinearRing>
<gml:coordinates>3366442.053224,5624025.159618....</gml:coordinates> </gml:LinearRing> </gml:outerBoundaryIs> </gml:Polygon> </location> </building></features>
XML element node based permissione.g. (+, Alice, read, /Building/owner)
XML element node based restrictione.g. (-, Alice, read, /Building/Price)
XML attribute node based restrictione.g. (-, Alice, read, /Building/@classification)
Background Information
5/32
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>1000000</price> <location> <gml:Polygon srsName="epsg:31467"> <gml:outerBoundaryIs> <gml:LinearRing>
<gml:coordinates>3366442.053224,5624025.159618....</gml:coordinates> </gml:LinearRing> </gml:outerBoundaryIs> </gml:Polygon> </location> </building></features>
content dependent permissione.g. (+, Alice, read, /Building, if /Building/price/text() < 2,000,000 $)
Background Information
6/32
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>1000000</price> <location> <gml:Polygon srsName="epsg:31467"> <gml:outerBoundaryIs> <gml:LinearRing>
<gml:coordinates>3366442.053224,5624025.159618....</gml:coordinates> </gml:LinearRing> </gml:outerBoundaryIs> </gml:Polygon> </location> </building></features>
spatial permissione.g. (+, Alice, read, /Building, if /Building/location/Polygon within USA)
Background Information
7/32
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>49.27 -123.11</gml:pos> </gml:Point> </disaster-location> ...<acs-context>
XML element node based context dependent permissione.g. (+, Alice, read, /Building, if current-time between 8am-6pm and
distance(/Building/location, /acs-context/disaster-location) < 500 meter)
Background Information
8/32
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-processingaccess control
WS response
post-processingaccess control
Background Information
9/32
Architecture of a Rule based Access Control System
Geodata Repositories
users WFS-
T PEP(WS)
XACML Access Control Decision Request
PAP (WS)
(Geo)XACML Rule Repository
XACML Access ControlDecision Response(s)
Authentication
Service
Access Control System
WS-Request/Response WS-Request/Response
security assertion (e.g. authent. data)
PDP(WS)
WPS
WMS
Administrators
Authentication
Service
Authentication
Service
Authentication
Service
security assertion (e.g. authent. data)
Authentication
Service
1
2
3
4
Background Information
10/32
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/32
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/32
Example
• Attributes destroy the hierarchical structure & semantical relationships and imply more generalized i.e. coarse-grained atomic information entities
<wfs:FeatureCollection ...> <gml:featureMember> <Building> <Owner>alice</Owner> <Price>1000000</Price> <Location> <Polygon @srs=„...“>...</Polygon> </Location> </gml:featureMember> <gml:featureMember> <Building> <Owner>bob</Owner> <Price>500000</Price> <Location> <Polygon @srs=„...“>...</Polygon> </Location> </gml:featureMember> <!--... more features ....--></wfs:FeatureCollection>
XACML Attributes
500000urn:???:price
1000000urn:???:price
boburn:???:owner
......
urn:...wgs84urn:???:srs
...urn:???:polygon
aliceurn:???:owner
AttributeValueAttributeName
• 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)
Representation of OWS data in decision requests
13/32
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/32
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/32
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 solutiono arbitrary information (i.e. node sets) under the ResourceContent
element can be selected & serve as input for functions in XACML rules
– easy solutiono no URN definitions necessary
(the standardized OGC XML schemas for OWS achieve uniqueness)o no attribute instantiation is necessary inside the PEP
• Conclusion:– use the ResourceContent/AttributeSelector approach to
represent OWS specific information in a XACML decision request
Representation of OWS data in decision requests
16/32
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
17/32
The AttributeSelector mechanism in the OWS context
WFS response in the a.c.d.r:<FeatureCollection> <featureMember> <building> <owner>...</owner> <price>1,000,000</price> <location>...</location> </building> <featureMember> <featureMember> <building> <owner>...</owner> <price>300,000</price> <location>...</location> </building> </featureMember> ...<FeatureCollection>
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>"500 000"])") > 0
</Rule>
Writing rules referring to OWS data in decision requests
18/32
Evaluation of the AttributeSelector mechanism
• only predicates supported by XPath can be used to define content dependant authorizationslimited 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
19/32
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[2]
/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]
Writing rules referring to OWS data in decision requests
20/32
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 mechanismperformance optimized processing is allowed as long
as the results are the sameWriting rules referring to OWS data in decision requests
21/32
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
22/32
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 authorizationslimited 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
23/32
Mechanisms for writing rules referring to OWS request or response information in the decision
request
spatial or arbitrary functions & predicates
flexible useof pointers
filtering
AttributeSelector no no no
Mult. and Hierarch. Resource Profile based
yes yes yes
XPath-node-match no no no
Writing rules referring to OWS data in decision requests
Conclusion:• Option 2 is the most expressive mechanism• depending on your requirements option 1 and 3 could also be used
24/32
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 onlylimited expressiveness
– PDP/PIP mechanism to request extra data needed during rule evaluation
– processing overhead possible
Pre-processing vs. Post-processing in the OWS context
25/32
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
Pre-processing vs. Post-processing in the OWS context
26/32
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
27/32
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
28/32
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
29/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
30/32
Important Change Requests for XACML 3.0 and profiles
• XACML 3.0– remove the new restriction that XPath expressions evaluated by an
AttributeSelector are not allowed to select element and attribute nodes (Line 2392-2395)
– e.g. datatype Geometry and <GML:Polygon>...</..>– some higher order functions are defined too restrictive (e.g. line
4556, 4590, 4786)• any-off, all-of signature (function, primitive data type, Bag)
– order of parameters? – functions with three or more parameters?
• map allow functions with more than one attribute (e.g. add 5 to each element in an integer bag)
– add urn:oasis:names:tc:xacml:3.0:attribute-category:web-service-request and urn:oasis:names:tc:xacml:3.0:attribute-category:web-service-response
• as this data belongs to the resource and action category at the same time– where to put namespace definitions of XML data under a Content
element– unnecessary constraint on the order of parameters of match
functions? reduced flexibility when new defined functions are added without its inverse counterpart.(1852)
31/32
Important Change Requests for XACML 3.0 and profiles
• Multiple and Hierarchical resource profile of XACML 3.0– rewrite these two profiles according to the ideas
introduced in this presentation - for details see the OGC OWS-6 GeoXACML Engineering Report (OGC 09-036r2 )
– reorganization of profiles?• Web Services profile of XACML 3.0 (based on a XML
resource profile of XACML 3.0)?– contains e.g. guidelines for the…
» creation of interoperable decision requests» definition of corresponding interoperable access
control rules» use of XACML’s obligation mechanism (e.g. ws-
request rewriting use case)…when using XACML to protect Web Services
32/32
thank you very much for your attention
questions, comments, ...?
Jan [email protected] Universität München
33/32
34/32
35/32
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
36/32
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
37/32
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
Representation of OWS data in decision requests
38/32
Baseline
• appearance of spatial data– KVP/Attributes– files (e.g. XML/GML)– spatial data bases– (O)WS-requests and –responses
http://...?location=<gml:Point><gml:pos>111.11 555.55</gml:pos> </gml:Point>
39/32
Starting point when defining access control rules
1. Read File Scenario
<features> <building classification="secret"> <owner> <name> <first>Bob</first> <last>Meyer</last> </name> <gender>male</gender> </owner> <price>1000000</price> <location> <gml:Polygon srsName="epsg:31467"> <gml:outerBoundaryIs> <gml:LinearRing> <gml:coordinates>....</gml:coordinates> </gml:LinearRing> </gml:outerBoundaryIs> </gml:Polygon> </location> </building></features>
Resource: XML/GML file + .xsd
<authenticationData> <subject> <name>Alice</name> <role>student</student> </subject> <authenticationMethod>Username/Password</...>...
Authentication Data
Access ControlSystem
<acs-context> <current-time>10 am</current-time> <disaster-location> <gml:Point>... </gml:Point> </disaster-location> ...<acs-context>
Access Control System Context
40/32
Starting point when defining access control rules
2. Web Service Scenario
Authentication Data
XML or KVP
WS request
XML or KVP
XML or unstructured
WS response
XML or KVP
Access Control System Context
Web Service
PEP
Geodata Repositories
PDP
(Geo)XACML Rule Repository
41/32
• 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/../..
42/32
Evaluation of the AttributeSelector mechanism
• only predicates supported by XPath can be used to define content dependant authorizationslimited 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>“500 000"])
</getUniqueXPath></nodesToFilter>
Writing rules referring to OWS data in decision requests
43/32
Mechanisms for writing rules referring to OWS request or response information in the decision
requestspatial or arbitrary functions & predicates
flexible useof pointers
filtering
AttributeSelector no no no
AttributeSelector+ Obligations
no no yes
Mult. and Hierarch. Resource Profile based
yes yes yes
XPath-node-match no no no
Writing rules referring to OWS data in decision requests
44/32
The structure of XACML related standards & profiles
OGC Web Service Profile of GeoXACML
XACML Core Specification
...SAML Profile
of XACMLRBAC Profile
of XACMLMultiple ResourceProfile of XACML
Hierarchical Resource
Profile of XACML
GeoXACML
Web Service Profile of XACML???