1 / 44

Access Control for OGC Web Services with (Geo)XACML

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

sari
Télécharger la présentation

Access Control for OGC Web Services with (Geo)XACML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 herrmanj@in.tum.de 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

  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 BackgroundInformation

  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>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 restrictione.g. (-, Alice, read, /Building/@classification) XML element node based permissione.g. (+, Alice, read, /Building/owner) XML element node based restrictione.g. (-, Alice, read, /Building/Price) BackgroundInformation

  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>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 $) BackgroundInformation

  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>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) BackgroundInformation

  7. Example 4: Declaration of a Context Dependent Rule 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) 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> BackgroundInformation

  8. Web Service pre-processingaccess control WS request post-processingaccess control WS response Geodata Repositories 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 BackgroundInformation

  9. Architecture of a Rule based Access Control System Access Control System 1 WFS-T users 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 ControlDecision Response(s) Geodata Repositories 2 PDP (WS) WMS AuthenticationService AuthenticationService AuthenticationService AuthenticationService AuthenticationService PAP (WS) WPS (Geo)XACML Rule Repository 4 Administrators BackgroundInformation

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

  11. Representation of OWS specific information in a XACML decision request Option 1: XACMLAttribute/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 semanticalrelationships 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>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> 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

  13. Representation of OWS specific information in a XACML decision request Option 1: XACMLAttribute/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 semanticalrelationships 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: XACMLAttribute/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: XACMLResourceContent/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: • XACMLAttribute/AttributeDesignator approach • Option 2: • XACMLResourceContent/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

  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>"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> <featureMember> <featureMember> <building> <owner>...</owner> <price>300,000</price> <location>...</location> </building> </featureMember> ... <FeatureCollection> 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 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 • 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 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 herrmanj@in.tum.de Technische Universität München

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

  35. 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 ControlSystem Access Control System Context <acs-context> <current-time>10 am</current-time> <disaster-location> <gml:Point>... </gml:Point> </disaster-location> ... <acs-context>

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

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

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

  39. Mechanisms for writing rules referring to OWS request or response information in the decision request Writing rules referring to OWS data in decision requests

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

More Related