Access Control for OGC Web Services with GeoXACML
Access Control for OGC Web Services with (Geo)XACML 69 th 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 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 2
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 3
Example 1: Declaration of Fine-Grained Access Rules <features> XML attribute node based restriction <building classification="secret"> e. g. (-, Alice, read, /Building/@classification) <owner> <name> <first>Bob</first> <last>Meyer</last> XML element node based permission </name> e. g. (+, Alice, read, /Building/owner) <gender>male</gender> </owner> XML element node based restriction <price>1000000</price> e. g. (-, Alice, read, /Building/Price) <location> <gml: Polygon srs. Name="epsg: 31467"> <gml: outer. Boundary. Is> <gml: Linear. Ring> <gml: coordinates>3366442. 053224, 5624025. 159618. . </gml: coordinates> </gml: Linear. Ring> </gml: outer. Boundary. Is> </gml: Polygon> </location> </building> </features> Background Information 4
Example 2: Declaration of a Content Dependent Rule <features> <building classification="secret"> content dependent permission <owner> e. g. (+, Alice, read, /Building, if <name> /Building/price/text() < 2, 000 $) <first>Bob</first> <last>Meyer</last> </name> <gender>male</gender> </owner> <price>1000000</price> <location> <gml: Polygon srs. Name="epsg: 31467"> <gml: outer. Boundary. Is> <gml: Linear. Ring> <gml: coordinates>3366442. 053224, 5624025. 159618. . </gml: coordinates> </gml: Linear. Ring> </gml: outer. Boundary. Is> </gml: Polygon> </location> </building> </features> Background Information 5
Example 3: Declaration of a Spatial Access Control Rule <features> <building classification="secret"> spatial permission <owner> e. g. (+, Alice, read, /Building, if <name> /Building/location/Polygon within USA) <first>Bob</first> <last>Meyer</last> </name> <gender>male</gender> </owner> <price>1000000</price> <location> <gml: Polygon srs. Name="epsg: 31467"> <gml: outer. Boundary. Is> <gml: Linear. Ring> <gml: coordinates>3366442. 053224, 5624025. 159618. . </gml: coordinates> </gml: Linear. Ring> </gml: outer. Boundary. Is> </gml: Polygon> </location> </building> </features> Background Information 6
Example 4: Declaration of a Context Dependent Rule Resource: <features> <building>. . <location>. . . </location>. . </building> </features> XML element node based context dependent permission e. g. (+, Alice, read, /Building, if current-time between 8 am-6 pm and distance(/Building/location, /acs-context/disaster-location) < 500 meter) Access Control System Context: <acs-context> <current-time>10 am</current-time> <disaster-location> <gml: Point srs. Dimension="2" srs. Name="urn: ogc: def: crs: EPSG: 6. 6: 4326"> <gml: pos>49. 27 -123. 11</gml: pos> </gml: Point> </disaster-location>. . . <acs-context> Background Information 7
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 WS request pre-processing access control post-processing access control • filtering • access control system based on standards Background Information Web Service WS response Geodata Repositories 8
Architecture of a Rule based Access Control System users Access Control System 1 WS-Request/Response security assertion (e. g. authent. data) WFS-T WS-Request/Response PEP (WS) 3 XACML Access Control Decision Request XACML Access Control Decision Response(s) Geodata Repositories 2 Authentication Service PDP (WS) WMS PAP (WS) (Geo)XACML Rule Repository WPS 4 Administrators Background Information 9
How to represent OWS specific information in XACML decision requests? • Option 1: – XACML Attribute/Attribute. Designator approach • Option 2: – XACML Resource. Content/Attribute. Selector approach Representation of OWS data in decision requests 10
Representation of OWS specific information in a XACML decision request Option 1: XACML Attribute/Attribute. Designator 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 11
you loose the relationships between nodes Example • you generate generalized i. e. coarse-grained atomic information entities loss of referencable information • – Attributes the hierarchical avoidable destroy only through generation ofstructure attributes & forsemantical each possible subset (c. p. srs) relationships and imply more generalized i. e. coarse-grained information entities atomic • XACML Attributes <wfs: Feature. Collection. . . > <gml: feature. Member> <Building> <Owner>alice</Owner> <Price>1000000</Price> <Location> <Polygon @srs=„. . . “>. . . </Polygon> </Location> </gml: feature. Member> <Building> <Owner>bob</Owner> <Price>500000</Price> <Location> <Polygon @srs=„. . . “>. . . </Polygon> </Location> </gml: feature. Member> <!--. . . more features. . --> </wfs: Feature. Collection> Representation of OWS data in decision requests Attribute. Name Attribute. Value urn: ? ? ? : owner alice urn: ? ? ? : owner bob urn: ? ? ? : price 1000000 urn: ? ? ? : price 500000 urn: ? ? ? : polygon . . . urn: ? ? ? : srs urn: . . . wgs 84 . . . 12
Representation of OWS specific information in a XACML decision request Option 1: XACML Attribute/Attribute. Designator 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 = { get. Map, get. Feature, transaction, insert, update, delete. . . }) Representation of OWS data in decision requests 13
Representation of OWS specific information in a XACML decision request Option 1: XACML Attribute/Attribute. Designator approach • information about OWS requests or OWS responses is represented as XACML Attributes in a XACML decision request • Conclusion Attribute/Attribute. Designator 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 14
Representation of OWS specific information in a XACML decision request Option 2: XACML Resource. Content/Attribute. Selector approach • information about OWS requests or OWS responses is represented under the XACML <Resource. Content> element only • Pros: – flexible and powerful solution o arbitrary information (i. e. node sets) under the Resource. Content element can be selected & serve as input for functions in XACML rules – easy solution o no URN definitions necessary (the standardized OGC XML schemas for OWS achieve uniqueness) o no attribute instantiation is necessary inside the PEP • Interim Conclusion: – use the Resource. Content/Attribute. Selector approach to represent OWS specific information in a XACML decision request Representation of OWS data in decision requests 15
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 16
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 17
Representation of OWS specific information in a XACML decision request • Option 1: – XACML Attribute/Attribute. Designator approach • Option 2: – XACML Resource. Content/Attribute. Selector 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 18
How to write rules referring to OWS specific information in a XACML decision request? • Option 1: using the Attribute. Selector 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 19
The Attribute. Selector 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 $ WFS response in the a. c. d. r: <Feature. Collection> <feature. Member> XACML Rule (highly simplified): <building> <Rule Effect="Deny"> <owner>. . . </owner> <price>1, 000</price> Attribute. Designator(subject-id) = "Alice" and <location>. . . </location> Attribute. Selector(“count(/Resource. Content/Feature. Collection/ </building> <feature. Member> feature. Member[building/price>"500 000"])") > 0 <feature. Member> </Rule> <building> <owner>. . . </owner> <price>300, 000</price> <location>. . . </location> </building> </feature. Member>. . . <Feature. Collection> Writing rules referring to OWS data in decision requests 20
Evaluation of the Attribute. Selector 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 21
The XACML Multiple and Hierarchical Resource Profile based mechanism in the OWS context • global access control decision request. . . resource-id = /Resource. Content[1]/wfs: Feature. Collection[1] scope = descendants (or children or immediate). . . • derived individual access control decision requests. . . resource-id = /Resource. Content[1]/Feature. Collection[1]/Feature. Member[1]/Building[1] scope = descendants /Resource. Content[1]/Feature. Collection[1]/Feature. Member[1]/Building[1]/owner[1] /Resource. Content[1]/Feature. Collection[1]/Feature. Member[1]/Building[1]/price[1] /Resource. Content[1]/Feature. Collection[1]/Feature. Member[1]/Building[1]/location[1] /Resource. Content[1]/Feature. Collection[1]/Feature. Member[2] • definition of a matching rule: <Rule Effect="Deny">. . . reg-expr-string-match(resource-id, /Resource. Content[d+]/Feature. Collection[d+]/Feature. Member[d+]) and Attribute. Selector(resource-id+"/Building/Price") > 500, 000 … Writing rules referring to OWS data in decision requests 22
Evaluation of the mechanism based on the XACML multiple and hierarchical resource profile • more expressive than the Attribute. Selector mechanism – all XACML and Geo. XACML 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 Attribute. Selector 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 23
The XPath-node-match mechanism in the OWS context • xpath-node-match(XPath_Expr 1, XPath_Expr 2) • 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: – expr 1: resource-id= /Resource. Content/Feature. Collection – expr 2: rule XPath /Resource. Content/Feature. Collection/Feature. Member/Building/price XPath-node-match(expr 1, expr 2) evaluates to true if there is a price element in the WFS Response Writing rules referring to OWS data in decision requests 24
Evaluation of the XPath-node-match mechanism • same limitations like the Attribute. Selector 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 25
Mechanisms for writing rules referring to OWS request or response information in the decision request spatial or arbitrary functions & predicates flexible use filtering of pointers Attribute. Selector no no no Mult. and Hierarch. Resource Profile based yes yes XPath-node-match no no no 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 26
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 27
Pre-processing access control for OWS with (Geo)XACML • the same mechanisms like for post-processing are available • WFS request: <Get. Feature> <Query type. Name="Building"> <Property. Name>owner</Property. Name> <Property. Name>price</Property. Name> <Property. Name>location</Property. Name> <ogc: Filter>. . . </ogc: Filter> </Query> </Get. Feature> • Problem: limitations when expressing content dependent pre-processing authorization semantics Pre-processing vs. Post-processing in the OWS context 28
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: get. Feature(Building, {Owner, Price, location}, Filter: Owner=State) – Rule: (+, Alice, Building) & Obligation: Price > 500, 000 – WFS request after AC/query rewriting: • get. Feature(Building, {Owner, Price, location}, Filter: Owner=State and Price > 500, 000) Pre-processing vs. Post-processing in the OWS context 29
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 30
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: get. Feature(Building, {Owner, Price, location}, Filter: Owner=State) • How to define the obligation? – Obligation: Price > 500, 000 get. Feature(Building, {Owner, Price, location}, Filter: Owner=State and Price > 500, 000) • Problem: WFS request language does only allow filters on Feature. Types and doesn’t allow filters on properties. Pre-processing vs. Post-processing in the OWS context 31
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 32
thank you very much for your attention questions, comments, . . . ? Jan Herrmann herrmanj@in. tum. de Technische Universität München 33
34
35
36
Baseline • appearance of spatial data http: //. . . ? location=<gml: Point><gml: pos>111. 11 – KVP/Attributes 555. 55</gml: pos> </gml: Point> – files (e. g. XML/GML) – spatial data bases – (O)WS-requests and –responses 37
Starting point when defining access control rules 1. Read File Scenario Resource: XML/GML file +. xsd Authentication Data <authentication. Data> <subject> <name>Alice</name> <role>student</student> </subject> <authentication. Method>Username/Password</. . . >. . . Access Control System Context <acs-context> <current-time>10 am</current-time> <disaster-location> <gml: Point>. . . </gml: Point> </disaster-location>. . . <acs-context> <features> <building classification="secret"> <owner> <name> <first>Bob</first> <last>Meyer</last> </name> <gender>male</gender> </owner> <price>1000000</price> <location> <gml: Polygon srs. Name="epsg: 31467"> <gml: outer. Boundary. Is> <gml: Linear. Ring> <gml: coordinates>. . </gml: coordinates> </gml: Linear. Ring> </gml: outer. Boundary. Is> </gml: Polygon> </location> </building> </features> 38
Starting point when defining access control rules 2. Web Service Scenario WS request Web Service XML or KVP PEP WS response Authentication Data XML or unstructured XML or KVP PDP Geodata Repositories Access Control System Context XML or KVP (Geo)XACML Rule Repository 39
• 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/. . 40
Evaluation of the Attribute. Selector 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. <nodes. To. Filter> <get. Unique. XPath> /Resource. Content/Feature. Collection/feature. Member[building/price >“ 500 000"]) </get. Unique. XPath> </nodes. To. Filter> Writing rules referring to OWS data in decision requests 41
Mechanisms for writing rules referring to OWS request or response information in the decision request spatial or arbitrary functions & predicates flexible use filtering of pointers Attribute. Selector no no no Attribute. Selector + Obligations no no yes Mult. and Hierarch. Resource Profile based yes yes XPath-node-match no no no Writing rules referring to OWS data in decision requests 42
43
The structure of XACML related standards & profiles OGC Web Service Profile of Geo. XACML Multiple Resource Profile of XACML Hierarchical Resource Profile of XACML RBAC Profile of XACML SAML Profile of XACML . . . XACML Core Specification Geo. XACML 44
- Slides: 44