Patterns for Access Control in a Multi-Protocol Environment Usage of SAML

SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 195 of 233

10.5.3 Patterns for Access Control in a Multi-Protocol Environment

The presented access control approach includes the extensive usage of OASIS Security standards. These standards have a focus on security enablement of SOAP messages and therefore the implemented access control architecture components cannot be directly applied to services with non SOAP bindings. As a matter of fact most OGC services and therefore a considerable number of service implementations that are part of SensorSA do not provide a SOAP binding yet. However, the available security service implementations are perfectly usable by utilising protocol adapters where necessary. SOAP WMS Proxy SOAP SOS Proxy Authorisation Service Integrated PEP Dedicated PEP WMS SOAP à HTTP Translator xsd:String SOS SOS SOAP à HTTP Translator xsd:String Client SOAP + Security Information WMS Authentication Service Integrated PEP Integrated PDP H T T P PO ST H T T P G ET PEP Proxy Figure 10-15: Access Control for HTTP based WMS SOS To use SensorSA security and access control mechanisms, service implementations with bindings according to the SensorSA OGC Web Services Platform see section 9.2.2 have to be equipped with SOAP interfaces protocol translatorsadapters. To this end, a number of protocol translators e.g. for WMS and SOS implementations is necessary as illustrated in Figure 10-9

10.5.4 Usage of SAML

SAML assertions issued by the Identity Management Authentication Service contain the following core elements: - Assertion ID: unique session id generated when the assertion is issued - Assertion IssueInstant: timestamp when the session was generated - Issuer: contains the End Point Reference to the IdP th at “issued” the assertion - Subject NameID: contains a unique id of the identity that is managed by the issuing IdP SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 196 of 233 - Conditions: describes which conditions must be fulfilled so that the assertion can be considered valid - SubjectConfirmation: Information on how to identify and validate session information - AuthnStatement: contains several information about the act of authentication, especially which form of credentials were provided - AttributeStatement: contains information about the identity‟s attributes unique id of the assertion and time the assertion was issued URI of the identity provider that issued the assertion Figure 10-16: Example of a Subject NameID unique id that identif ies the subject authenticated identity within the identity provider random session key, also used to verif y the validity of the assertion currently via IDP operation verifySessionInformation issue- and expiration-time, used to conf irm the validity of the assertion Figure 10-17: Example of a Subject Confirmation SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 197 of 233 Figure 10-18: Example of an Authentication Statement attributes asserted with the authenticated identity Figure 10-19: Example of an AttributeStatement Figure 10-20 indicates where SAML plays a role in relation to the abstract access control pattern see 6.7.2. SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 198 of 233 service request r + t à ß service response p AP Subject Service PEP PIP PAP PDP IdP r à authentication response request policy for

r,t

XACML policy ß ß ß ß ß ß ß ß ß p samla = SAML assertion schema samlp = SAML protocol schema xacmlsp = SAML 2.0 profile of XACML 2.0 protocol schema samlp:AuthnRequest xacmlsp: XACMLAuthzDecisionQuery xacmlsp: XACMLAuthzDecisionStatement t samlp:Response samla:Assertion[s] verify samla:Assertion[s] authenticate t Figure 10-20: SAML in relation to the Access Control Pattern 10.5.5 Usage of XACML This paragraph provides a simple example of how to use the basic XACML constructs described in section 7.4.6.2.

10.5.5.1 Example SOS Policy

Translated to plain English the policy below specifies that for the service SoapBindingsSOSv3WS0 1 only those XACML subjects which are members of the group SOS User have read access. Further, the requested action must be getObservation. All of these properties are mapped in XACML policies via attributes, which are basically key value pairs. Due to this characteristic of XACML, it is possible to express arbitrary real world concepts as properties, e.g. roles, groups, company branch or department. Because there is a lot of boilerplate XML in the example code the interesting parts are marked in red boxes. For simplicity and better comprehension the ... notation indicates that some parts of the policy document are omitted.