access control for ogc web services with (geo)xacml

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

Jan [email protected]

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)


5/32

Example 2: Declaration of a Content Dependent Rule




content dependent permissione.g. (+, Alice, read, /Building, if /Building/price/text() < 2,000,000 $)


6/32

Example 3: Declaration of a Spatial Access Control Rule




spatial permissione.g. (+, Alice, read, /Building, if /Building/location/Polygon within USA)


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)


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


9/32

Architecture of a Rule based Access Control System


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


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


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

13/32



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


14/32



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.


15/32


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


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>


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


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]


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


22/32

Evaluation of the XPath-node-match mechanism

• same limitations like the AttributeSelector mechanism



• filtering is not possible– the XACML decision response refers to the Web Service

request or response as a whole


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


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


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)


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


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.


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

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.


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)


37/32


• 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


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


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



• filtering is not possible solvable through special obligations: e.g. <nodesToFilter>

<getUniqueXPath>/ResourceContent/FeatureCollection/featureMember[building/price>“500 000"])

</getUniqueXPath></nodesToFilter>


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


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

access control for ogc web services with (geo)xacml

Documents

access control rules

access control system

xacml decision requests

context dependent permission

xacml decision requestoption

content dependent permission

spatial permission

context dependent ruleresource