Copyright © 2013 Open Geospatial Consortium
20 response is going to be filtered, matching the user’s ability to not see restricted
service endpoints. Access Control in place for Web Feature Services in a fine grained fashion to
ensure that denied data sets, down to the location of a feature or characteristics of the feature, are not accessible.
6.1 Use Case
The full use case description – as a 100 copy from the OWS9 portal – can be found in the annex A to this document.
Regarding security, the following sub sequence of the use case is important: An actor of the Integrated Client undertakes a catalogue search for determining Web Feature Services
that provide data sets on Haiti and Monterey. The user leverages a Cataloge Service for the Web CSW interface. The result of the search is presented as an OWSContext
document where particular portions are filtered according to the need-to-know principle.
The user can leverage the received information to either have a client to execute a semantic mediator or execute the protected Web Feature Services WFSs directly.
6.2 Architecture and Deployment
A user is making a Catalogue search from a mobile application using the CSW 2.0.2 interface. The response retuned to the application is an OWSContext document
containing all service resource offerings matching the request for which the user has the clearance to see. In other word, the actual response is a subset of response the service
produces. All service resource offerings for which the user has no need-to-know get removed from the service response.
In order to achieve this, the following architecture is used:
Figure 13 —Architecture to filter CSW responses based on user clearance
Copyright © 2013 Open Geospatial Consortium
21 The sequence of interactions between the modules is described in the following sequence
diagram.
Figure 14 — Interactions between the security components and the CSW
The following are the details for the interactions 1. A client submits a “Get Records” operation. This request is not directly
executed at the CSW, instead it is intercepted by the PEP. 2. The PEP analyses the request and creates a XACML 2.0 compliant
Authorization Decision Request ADR. This ADR contains information about the user Role, all parameters of the CSW request and environment
information such as Date and Time. In addition, the ADR contains information about the HTTP method and the request context ‐ CSW request.
3. The PEP sends the ADR to the PDP. 4. The PDP analysis the ADR and applies the policy which matches the request
context CSW request plus user Role, CSW operation, etc. 5. The PDP finds a matching Policy and derives the Authorization Decision
AD. Because the ADR was a XACML 2.0 Core request, only one decision is included into the AD. However, the AD must be PERMIT but in order to task
the PEP to request authorization decisions based on the CSW response for
Copyright © 2013 Open Geospatial Consortium
22 the purpose of filtering, an Obligation must be included. For the Secure
Dimensions PEP, this Obligation must indicate the ObligationID=to‐do. 6. The PEP receives the AD and analysis it. Because the decision is PERMIT, it
will continue processing the AD and find the Obligation. Processing of the Obligation id has the side effect that a flag is set to construct a XACML 2.0
MRP ADR based on the CSW response. 7. The PEP forwards the intercepted request to the CSW and receives the CSW
response, e.g. a OWS Context document. 8. The further processing of the CSW response is under the flag for XACML 2.0
MRP. This requires that a ADR including MRP is constructed and that the two required parameters are copied from the Obligation, received in the AD for
the CSW request. Also, the PEP must include the received CSW response into the Resource Content element of the ADR and the request context must be
set to CSW response. 9. The ADR is send to the PDP.
10. The PDP analysis the ADR and understands, that XACML 2.0 MRP compliant processing is required. In order to do that, it must produce individual
authorization decisions for each XML element of the Resource Content that matches the provided xpath expression in the resource‐id attribute.
11. For each matching XML element, the PDP creates an individual authorization decision by analyzing the existing policy. A decision for each element
comprises the resulting AD. 12. The PEP receives the AD for the intercepted CSW response and removes all
those XML elements for which the authorization decision is Deny. After all authorization decisions are processed, the CSW response is filtered, meaning
that all XML elements got removed for which the user has no permission to see.
13. After error free processing, the PEP forwards the shrunk CSW response to the client. It is important to note that the security was applied in an opaque
fashion, so the user does not know. This processing implies that certain criteria are met when writing the policy.
6.3 Approach to Policy writing for CSW response filtering
