Glossary Item Box

Government Gateway 2.2.0 (MR-01) ISV Developer Help (Doc Version 06/03/08) | Send comments on this topic.

# Security Token Service

While UsenameTokens or X509SecurityTokens provide message authentication and, in the case of an X509SecurityToken message, validation through signing, the need to create a new security token each time a method is invoked can be time consuming. For Web Portals it also raises potential implementation issues:

- For users with a certificate credential, each method the Web Portal invokes requires the SOAP request to be signed at the client's computer.
- For users with a User ID/password credential, caching the user's (hashed) password on the Web Portal, so new UsernameTokens can be created, can have security implications.

The Security Token Service (STS), which with release 1.7.0 fully conforms to the WS-Trust specification, manages the authentication of user credentials. Its primary role is to issue "reusable" GatewayTokens to authenticated users that can then be used with (and trusted by) methods on the Gateway SOAP Portal or Public Interfaces.

The URL endpoints for the Web services STS interface used to request GatewayToken are:

- https://secure.gateway.gov.uk/soap/2007/02/sts/GatewayTokenService.ashx for a "Standard" GatewayToken.
- https://secure.gateway.gov.uk/soap/2007/02/sts/NonRepudiationGatewayTokenService.ashx for a "Non-Repudiation" GatewayToken. Note no methods available through the SOAP Public need this.

> > Note: These endpoints support the WS-Trust <wst:Lifetime> element in STS request (rather than the non-conformant <wst:LifeTime> element). STS requests that use <wst:lifeTime> can continue to use the legacy endpoints: https://secure.gateway.gov.uk/soap/sts/GatewayTokenService.ashx and https://secure.gateway.gov.uk/soap/sts/NonRepudiationGatewayTokenService.ashx – however migration should be planned.

To obtain a GatewayToken a RequestSecurityToken (RST) message is sent to the STS. A UsernameToken or an X509SecurityToken is included in the RST message to authenticate the caller. The standard GatewayToken is returned from the STS in a RequestSecurityTokenResponse (RSTR) message. The client (Portal or application) then incorporates this GatewayToken into the SOAP messages for calls to methods on the SOAP Portal or Public Interface. These methods (in the Gateway) check the validity of the GatewayToken before performing the requested operation.

The STS and Gateway security architecture and implementation is based on the following design decisions:

- Gateway Web services do not inherently trust users
- STS is trusted by the Gateway Web services
- STS can create GatewayTokens, SAML Assertions and TicketBooks security tokens based on authenticated UsernameTokens and X509SecurityTokens
- STS can exchange GatewayTokens, SAMLAssertion and TicketBook security tokens
- Broker (Web Portal)
  - The Broker is trusted by both the STS and the Gateway Web services
  - There is a mutual SSL session between the Broker, the Gateway Web services and the STS
  - There is an SSL session (not mutual SSL) between the user (browser) and the Broker
- ISV applications
  - There is an SSL session between the ISV application and Gateway Web services and the STS

© Crown Copyright 2008. All rights reserved