With respect to the enablement of federated identity, Web services have advantages over traditional Web applications because Web services technologies natively support the externalization of subject authentication in a standard way. This is facilitated through dedicated security services provided by the infrastructure (WS-Trust STSs). However, when it comes to advanced identity federation use cases demanding more sophisticated federation features, Web services also suffer from a scattered technology landscape not easily accessible for non-experts. This landscape at least comprises WS-Federation, Liberty-Alliance ID-WSF, OASIS WSFED. This contribution investigates these Web services federation technologies. It uses a health- care use case that demands sophisticated features in identity federation to pinpoint their capabilities. Moreover, it considers the identity federation enablement features of common Web services stacks e.g. Apache Axis, Microsoft WCF and Sun Metro. This aims at providing a compass for those who are charged with architecting, designing and building identity federation solutions in Web services environments: Which technologies are out there? What are they good for? How are they supported in Web services stack?
The wishlist comprises: Do address following use cases: Single-sign-on (considered here) Name identifier management … Single-sign-out Do this trick for Web applications Web services (considered here)
Informally: a special brand of Web applications with XML-based service contract: WSDL XML-based protocol stack: IP-TCP-(SSL/TLS)-HTTP- SOAP-DIY Note: WSDL and SOAP are W3C recommendations (aka standards)
Simple data types (string, integer, date…) are defined by XML Schema Compound data types are defined by e.g. OASIS for specific domains (e.g. provisioning, authorization, federation) Further complex data types can be defined (e.g. CardSpace, eFA, custom…)
Security token = identity assertion
SAML assertions provide a standard format to securely marshal authenticated subject information for WSs and traditional Web applications: WSs support holder-of-key subject confirmation models Web applications are limited to bearer models WSs have a native understanding about their handling (Web applications do not): Request SAML assertions: through WS-SecurityPolicy sections in WSDLs Issue SAML assertions: through WS-Trust STS WSs ( sp:IssuedToken ) or arbitrary WSs ( sp:SamlToken ) Transfer SAML assertions: as child elements of wsse:Security SOAP headers (Almost) all is off-the-shelf: WS-stacks natively support request, transfer and parsing of SAML assertions Issuance requires WS-Trust STSs or STS-style WSs; the supply and consumption of SAML assertion contents (usually) is solution-specific
Expect WS-Trust STSs to deliver the basic enablement services for identity federation; additional requirements should be covered by making use of extension points in WS-Trust.