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.