What is an STS and why do we have so many of them?
In the broad category of message-oriented security in web services, each message contains a security token; in SOAP messages these are provided in the Security section in the SOAP header. In some of the more common usage patterns, that token is provided by a different node than the originating requester or the policy enforcement point.
We call the provider of the token a “secure token service” or STS. Even though the diagrams often show the STS as a separate node, the CA API Gateway can often act as both the STS and the policy enforcement point.
In broad terms, an STS receives some kind of credential from a given user and presents the user with a token that represents the user’s identity without sending the credentials again. By sending the token you present proof of your identity, but you hold the reusable part i.e. your password private. This lets you send a strongly verifiable token outside of your local sphere of security to another security zone without providing them with a token that could be hijacked and used outside its original purpose.
By far SAML is the most common form of token mentioned in the same conversations with STS but other kinds of tokens are possible, most notably WS-SC session tokens. We support quite a few common usages that all draw on a common token issuing capability core to the product. In some cases the tokens issued are automatic and present to enable a specific use case and in other cases these are under extremely detailed user control to present a flexible and open ended tool chain.
Secure Token Services in the CA API Gateway
The CA API Gateway supports quite a few patterns of STS usage based on several common use cases.
Internal STS
Our built in STS was built to support our XVPNC and so has a great deal of automated self configuration based on the policies in the local gateway. For the basic use cases, it does everything that is needed for the Holder of Key style of SAML.
Client software, including the XVPNC, crafts a WS-Trust Request for Security Token (RST) that the STS responds to with a Request for Security Token Response (RSTR) as specified in the WS Trust WSDL. Inside the RSTR is a standard SAML token with only an Authentication Statement and signature. The client software binds this token into their request message and sends it to the target service that accepts SAML tokens. That RST can be authorized using any method that local gateway hosting the STS supports, to any identity provider used in any local policy that has a SAML token as a credential source.
By far the most common use of the internal STS is receiving an RST with HTTP Basic credentials over HTTPS and responding with an RSTR.
WS-SC session token
The internal STS also supports creating tokens for WS secure conversation. This is a kind of symmetric message encryption token that allows you the same privacy of message based security, without the per-request CPU overhead of public key cryptography that the SAML pattern has. As with the internal SAML capabilities, it responds to an RST with an RSTR, and the credentialing pattern is the same too: Any configured credential type and any configured identity source.
SAML Holder of Key: In the Routing Assertion(s)
As with the internal STS there’s also an internal STS issuer capability for outbound messages built into the routing assertions that is also automatically configured: The routing assertions create new Security Headers in messages that contains a simple Holder of Key SAML assertion that simply attests that whatever kind of inbound credentials that were present in the message were validated.
This is the simplest case for the credential upgrade pattern for client software that can’t currently support SAML: client software sends locally verifiable credentials and the gateway automatically issues a SAML token that attests that the credentials were good.
SAML Issuer Assertion
As the internal STS in any of the above cases is not particularly configurable, we then created the SAML Issuer assertion. This is a fully featured SAML Token issuing capability, with authentication, authorization and attributes statements all as configurable elements. These tokens can be bound into messages, or left as standalone to operate in more complex policies
SAML Issuer: Holder of Key
In the Holder of Key profile, we can use this to issue a SAML token, vouching for the inbound credentials to any downstream consumer.
In effect, the credentials in an inbound user request are traded up for another kind of credential in policy operation. Because it is used in policy operation, and has the benefit of all of our policy language, you can issue complex tokens with attributes and decision statements in addition to the standard authentication statement. This allows you to act as a secure egress gateway for internal users to consume external services without fear that their credentials will be exposed to external requests.
Issuer Assertion as WS-Trust Service
This effectively combines two of the above ideas into a single service: RST/RSTR pattern, using a specifically configured Issuer assertion as the core token issuer.
Typically to support complex use cases, the same kind of inbound request for security token is sent to a specifically crafted service created by specifically publishing the WS-Trust WSDL on theCA API Gateway. Because the WSDL is explicitly published and is under policy control, this means that the user can be very specific about the allowed inbound credential types, the identity providers where those credentials can be verified and the specifics for the token. The format of the RSTR must be explicitly set as well as the configuration of the RSTR signature.
In some ways this is the complete opposite of the built in service in that everything must be explicitly set up: publishing the service, creating a policy with credential types, verification, the token issuer itself and the creation of the response message.
STS Client
XVPNC
As mentioned above, the XVPNC acts as a client to our built in STS. Additionally, the XVPNC can request SAML tokens from other STS implementations like TFIM and ADFS/Indigo. These capabilities allow the same usage pattern in situations that have extant STS capability.
Gateway
We have some quite unique capabilities in this area: We include a HTML form post and SAML-P callout capability to access external identity providers and attribute services as part of policy operation. This lets us act in several usage patterns including Holder of Key outbound from the gateway, while still acting in a credential exchange role. We can also answer SAML-P requests and in a forthcoming version we’re adding some more sophisticated capabilities around SAML Browser Profile to be able to act as an STS for more use cases. We’ve further been integrating with the STS that is part of WCF for WS-SC on back end requests.
Conclusion
Currently we support incoming, outgoing, pass through and standards compliant STS services. We go well beyond the easy use cases with configurable and ad-hoc services to meet business needs. There are few limitations imposed by these capabilities in the services model, and we can also address selected requirements in the browser profile model.