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

2. 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. 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. 4/32 Example 1: Declaration of Fine-Grained Access Rules Bob Meyer male 1000000 3366442.053224,5624025.159618.... XML element node based permission e.g. (+, Alice, read, /Building/owner) XML element node based restriction e.g. (-, Alice, read, /Building/Price) XML attribute node based restriction e.g. (-, Alice, read, /Building/@classification) Background Information

5. 5/32 Example 2: Declaration of a Content Dependent Rule Bob Meyer male 1000000 3366442.053224,5624025.159618.... content dependent permission e.g. (+, Alice, read, /Building, if /Building/price/text() < 2,000,000 $) Background Information

6. 6/32 Example 3: Declaration of a Spatial Access Control Rule Bob Meyer male 1000000 3366442.053224,5624025.159618.... spatial permission e.g. (+, Alice, read, /Building, if /Building/location/Polygon within USA) Background Information

7. 7/32 Example 4: Declaration of a Context Dependent Rule Resource:........... Access Control System Context: 10 am 49.27 -123.11... 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. 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-processing access control WS response post-processing access control Background Information

9. 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 Control Decision Response(s) Authentication Service Access Control System WS-Request/Response security assertion (e.g. authent. data) PDP (WS) WPS WMS Administrators Authentication Service security assertion (e.g. authent. data) Authentication Service 1 2 3 4 Background Information

10. 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. 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. 12/32 Example Attributes destroy the hierarchical structure & semantical relationships and imply more generalized i.e. coarse-grained atomic information entities alice 1000000... bob 500000... 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. 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. 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. 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 element only Pros: –flexible and powerful solution oarbitrary information (i.e. node sets) under the ResourceContent element can be selected & serve as input for functions in XACML rules –easy solution ono URN definitions necessary (the standardized OGC XML schemas for OWS achieve uniqueness) ono 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. 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. 17/32 The AttributeSelector mechanism in the OWS context WFS response in the a.c.d.r:... 1,000,000...... 300,000...... Intended authorization semantic: Alice is not allowed to read Building data if the building’s price is above 500,000 $ XACML Rule (highly simplified): AttributeDesignator(subject-id) = "Alice" and AttributeSelector(“count(/ResourceContent/FeatureCollection/ featureMember[building/price>"500 000"])") > 0 Writing rules referring to OWS data in decision requests

18. 18/32 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 Writing rules referring to OWS data in decision requests

19. 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:...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. 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 mechanism  performance optimized processing is allowed as long as the results are the same Writing rules referring to OWS data in decision requests

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

23. 23/32 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 AttributeSelectorno Mult. and Hierarch. Resource Profile based yes XPath-node-matchno 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. 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 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

25. 25/32 Pre-processing access control for OWS with (Geo)XACML the same mechanisms like for post-processing are available WFS request: owner price location... Problem: limitations when expressing content dependent pre-processing authorization semantics Pre-processing vs. Post-processing in the OWS context

26. 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. 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. 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. 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. 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... –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. 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/32 thank you very much for your attention questions, comments,...? Jan Herrmann herrmanj@in.tum.de Technische Universität München

33. 33/32

34. 34/32

35. 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. 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. 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. 38/32 Baseline appearance of spatial data –KVP/Attributes –files (e.g. XML/GML) –spatial data bases –(O)WS-requests and –responses http://...?location= 111.11 555.55

39. 39/32 Starting point when defining access control rules 1.Read File Scenario Bob Meyer male 1000000.... Resource: XML/GML file +.xsd Alice student Username/Password... Authentication Data Access Control System 10 am...... Access Control System Context

40. 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. 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. 42/32 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. /ResourceContent/FeatureCollection/featureMember[building/price >“500 000"]) Writing rules referring to OWS data in decision requests

43. 43/32 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 AttributeSelectorno AttributeSelector + Obligations no yes Mult. and Hierarch. Resource Profile based yes XPath-node-matchno Writing rules referring to OWS data in decision requests

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