OGC 07-118r9
34
Copyright © 2014 Open Geospatial Consortium
wst:RequestType http:docs.oasis-open.orgws-sxws-trust200512Issue
wst:RequestType wsse:UsernameToken
wsse:Username JohnDoe
wsse:Username wsse:UsernameToken
wst:RequestSecurityToken
6.4.3.4 Delegate STS with External IdP
The present case is in essence similar to the Local STS with External IdP case for the first part and to the Delegate STS as IdP case for the second part.
For this present case, the RST with signature is used. It contains a “DelegateTo” element containing a wsa:Address with an identifier URI for the delegate STS. A mapping table
between identifiers and supported external STS URLs shall be maintained by the local STS. No delegation is performed if the identifier is not configured in this table.
Figure 8: Delegate STS with External IdP
Scenario: 1. An authentication request is sent to the external IdP authentication mechanism
specific to Web-SSO system used, out of scope of the present Best Practice. 2. The external IdP verifies the user identity specific to Web-SSO system used.
3. The authentication response is returned to the Client specific to Web-SSO system used.
OGC 07-118r9
35
Copyright © 2014 Open Geospatial Consortium
4. If the authentication was successful, the Client prepares an RST with the user id no password and a WS-Trust “DelegateTo” element; the Client signs it with its private
key. 5. The RST with signature is sent to the local delegating STS using SOAP over
HTTPS. 5
b
. Optionally
14
, the delegating STS verifies the signature of the RST, based on the set of registered clients public keys stored beforehand in the STS keystore, as trusted
Clients; this succeeds. The delegating STS then removes the signature and re-signs the RST with its own private key. It may also convey the Client’s identifier e.g.
urn:ceos:def:epr:esa-cds:1.0:portal-1 to the delegate STS in the “OnBehalfOf” element.
6. The delegating STS sees that an identifier of external STS is specified in the RST in the WS-Trust “DelegateTo” element; it redirects the RST to the designated external
delegate STS. The URL of this IdP is extracted from the mapping table previously described.
7. The delegate STS verifies the signature of the RTS, based on the set of registered clients public keys stored beforehand in delegate STS keystore, as trusted Clients
or, optionally step 5
b
, based on the delegating STS’s public key ; this succeeds.
8. The delegate STS creates the SAML token using the attributes retrieved from the user registry.
9. The RSTR containing the SAML token, unsigned and in clear, is returned to delegating STS, through SOAP over HTTPS.
10. The delegating STS signs the SAML token using its private key. 11. The delegating STS encrypts the SAML token with the Relying Partys public key
see subsection 6.4.1.1 for the process of key retrieval. 12. The RSTR containing the signed and encrypted SAML token is returned to the Client
using SOAP over HTTPS. The steps 7, 8 and 9 in the above scenario require that the external STS acts as a delegate
STS, to ensure that the SAML token is returned in clear and unsigned. For that purpose, the decision tree presented in 6.4.3.2 shall be used.
14
To avoid the configuration of public keys on all the delegate STS whenever a new Client is
added.
OGC 07-118r9
36
Copyright © 2014 Open Geospatial Consortium
6.4.4 Service Request
