OGC 07-118r9
18
Copyright © 2014 Open Geospatial Consortium
6 System context
This section documents special requirements and describes the context of use.
6.1 Application domain
Web service requests are received by Service Providers. These Service Providers should be able to identify who issued the request and react accordingly. The following approach is
proposed:
1 A Security Token Service STS provides a Request Security Token operation RST, which returns a SAML token, an artefact representing an authenticated user.
Depending whether the STS is in charge of authentication or not, two main cases are defined:
a. The STS is in charge of authentication: the RST contains user identifier, password and optionally his identity provider. This service may delegate the
authentication and SAML token generation to another STS acting as an identity provider.
b. The STS is not in charge of authentication, i.e. this is taken in charge by an external IdP Web-SSO, which is trusted by the STS: the RST just contains a
user identifier no password; it shall be signed in order to check that the requester is trusted. This service may delegate the SAML token generation to
another STS. 2 Each subsequent service request by the client Web service consumer should include
the SAML token as described later in this document. 3 Each Service Provider accepts service requests only via an Authorisation Service or
Policy Enforcement Point PEP. The PEP first checks the existence of SAML token and decrypts it.
4 The PEP verifies the SAML token signature and expiry time 5 The PEP decides based on the content of the message body, the contents of the
message header including authentication token and the context i.e. applicable policies whether to accept or to refuse the service request or to reroute it. Although
this is not imposed, the use of XACML [NR21] or GeoXACML [NR25] for definition of policy rules is recommended.
6 If the request is authorised, then the request is forwarded to and processed by the target SP.
If any of the steps from 3 to 5 fails, then a fault response is returned to the client.
OGC 07-118r9
19
Copyright © 2014 Open Geospatial Consortium
The full authentication authorisation process is detailed in the following figure. This figure highlights the typical sequence of steps from authentication to request authorisation and
processing the two authentication cases are here abstracted.
Figure 1: Sequence of authenticationauthorisation activities
The distinction between steps 1.a. and 1.b, which discriminate on the IdP responsibility, is depicted in the following diagram client A authenticates on STS, client B authenticates on
external IdP.
Figure 2: Two cases of authentication
These two cases are refined and detailed in section 6.4.3.
OGC 07-118r9
20
Copyright © 2014 Open Geospatial Consortium
6.2 Protocol bindings
