Header Image

Security Token Service for Service Federation

Identity STS

The Problem: Cross-Domain Information Sharing

Sharing application data and functionality over the Internet to external divisions and partners requires trust between two applications in different identity domains. Establishing this trust in user-machine interactions is challenging, and harder still in machine-to-machine SOA and cloud environments.

For a client application in one domain to request information from a Web service residing in a different domain, the client will need to present proof of its identity using a credentialing authority trusted by the Web service. The receiving service will need to be able to understand and evaluate the presenting credentials to asses an identity’s validity while also having evidence that the credentials were not tampered with or spoofed during transit. The challenge therefore is in finding a way to both federate identity and establish trust between machines in disparate identity domain.


Solution: PKI + STS = Trust

Several identity federation products have been introduced in recent years based on a Security Token Service for handling identity mapping and secure token generation. However, these products tend to focus on Web Single Sign-on and Web federation since they implicitly leverage Web browsers for handling trust (through user inputted credentials), client-side cookie or token caching and address redirection. Since there is no browser analogue in Web services, the problem of trust, token acquisition, token caching and token transmission is more complicated.

To enable interactions between client applications and Web services residing in different identity domains, both the client application and Web service must be able to establish trust with another and exchange identity information that has meaning in both domains. In machine-to-machine SOA and cloud interactions this will require some kind of PKI based mechanism for establishing trust between a client application and Web service. Moreover to reconcile identity information, both the client and service will need to interact with a trusted Security Token Service (STS) that can handle SAML token generation, translation and validation between identity domains. For Web services clients this will require both an ability to generate digital certs and an ability to request a secure token from an STS that provides proof of identity in the Web services domain from an STS, package it into a signed SOAP call and transmit the secured SOAP message to a Web service. For a Web service this requires an ability to consume and process the secure token generated by the STS and then use it to make authentication and authorization decisions along with generating new credentials for down stream transmission. Given the diversity of token types, multi-vendor STS’s needing support, complexity of PKI and evolution of Web services security standards like WS-Trust and WS-Federation, the problem of enabling secure Web services federation is likely to challenging for developers to handle themselves.


Layer 7 Value: Federated Identity for SOA & Cloud with Built-in STS

Layer 7 is the only XML security vendor to offer enterprises a solution for managing Web services federation from client application to Web service without programming as well as a provide a built-in SAML based Secure Token Service. The Layer 7 Web service federation solution can integrate with leading identity management, federation and security token services. The Layer 7 SecureSpan XML Firewall and the SecureSpan SOA Gateway also provide customers a flexible SAML based Security Token Service (STS) appliance for consuming, validating, creating and transforming security tokens including Kerberos, SAML 1.1 and 2.0. Likewise the SecureSpan XML VPN Client provides a admin-configurable tool for establishing PKI based trust on a client application, managing token requests from an STS (3rd party of Layer 7), and packaging a token into a secure SOAP call. Layer 7’s SecureSpan XML VPN automatically manages token negotiation using standards like WS-Trust, WS-Federation, and packaging of SOAP calls on the client application using WS-Security and WS-I Basic Security Profile to name some standards. All this is accomplished with zero upfront code and no down-time for policy updates.