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 herrmanj@in.tum.de Technische Universität München Department of Informatics Chair for Applied Informatics / Cooperative Systems

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.

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

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 attribute node based restriction e.g. (-, Alice, read, /Building/@classification) XML element node based permission e.g. (+, Alice, read, /Building/owner) XML element node based restriction e.g. (-, Alice, read, /Building/Price) Background Information

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 permission e.g. (+, Alice, read, /Building, if /Building/price/text() < 2,000,000 $) Background Information

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 permission e.g. (+, Alice, read, /Building, if /Building/location/Polygon within USA) Background Information

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> ... 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

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

Architecture of a Rule based Access Control System 1 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

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

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

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>1000000</Price> <Location> <Polygon @srs=„...“>...</Polygon> </Location> </gml:featureMember> <Owner>bob</Owner> <Price>500000</Price> <!--... more features ....--> </wfs:FeatureCollection> AttributeName AttributeValue urn:???:owner alice urn:???:owner bob urn:???:price 1000000 urn:???:price 500000 urn:???:polygon ... urn:???:srs urn:...wgs84 ... ... Representation of OWS data in decision requests

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

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

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

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

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

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

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

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>"500 000"])") > 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

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

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

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

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

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

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

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

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

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

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

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

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

thank you very much for your attention questions, comments, ...? Jan Herrmann herrmanj@in.tum.de Technische Universität München

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 http://...?location=<gml:Point><gml:pos>111.11 555.55</gml:pos> </gml:Point>

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>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> <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> ...

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

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/../..

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>“500 000"]) </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

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

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