• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
State-of-the-Art in Web Services Federation
 

State-of-the-Art in Web Services Federation

on

  • 1,592 views

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 ...

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?

Statistics

Views

Total Views
1,592
Views on SlideShare
1,591
Embed Views
1

Actions

Likes
1
Downloads
0
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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.

State-of-the-Art in Web Services Federation State-of-the-Art in Web Services Federation Presentation Transcript

  • State-of-the-Art in WebServices FederationEuropean Identity Conference 2009Dr. Oliver Pfaff Copyright © Siemens AG 2009. All rights reserved.
  • What’s Next?Dive deeper into identity federation for Web servicesKey points for this discussion: Web services vs. traditional Web applications – what is the Web services magic? Asking for identity assertions vs. expressing them vs. supplying them – what makes the real difference?Presentation overview: Setting the scene About Web services Good news But things complicate quickly Conclusions and outlook Copyright © Siemens AG 2009. All rights reserved.Page 2 May 2009 Siemens IT Solutions and Services
  • Setting the SceneReminder: A ‘Simple’ Trick Needs To Be Done Resource provider User Request identity assertions Authorization Supply identity assertions Resource Authentication User data Identity provider Copyright © Siemens AG 2009. All rights reserved. Page 3 May 2009 Siemens IT Solutions and Services
  • Setting the SceneMain Aspect#1: Acquiring Identity Assertions Expressiveness requirements: Request identity assertions: articulate the need to present identity assertions and express expectations on their issuer, contained information and their security binding Supply identity assertions: embody identity assertions with protocol primitives of the given protocol stack Security requirements: Proof-of-possession (for identity assertions): verify that it is actually John Doe who presents an identity assertion such as: authentication authority says: this is ‘John Doe’, an employee of ‘acme.example’ with the role ‘manager’ Copyright © Siemens AG 2009. All rights reserved. Page 4 May 2009 Siemens IT Solutions and Services
  • Setting the SceneMain Aspect#2: Asserting Identity Expressiveness requirements: IdM: imprint arbitrary subject identifiers (e.g. X.500 distinguished names, RFC 822 names) and subject attributes (e.g. statically/dynamically assigned) Authentication (of users): support arbitrary authentication schemes and authentication process-related metadata e.g. level of assurance Authorization: enable the supply of subject-related authorization decisions/policies Security requirements: Authentication (of identity assertions): verify the authenticity of identity assertions Copyright © Siemens AG 2009. All rights reserved. Page 5 May 2009 Siemens IT Solutions and Services
  • About Web ServicesDefining Web Services A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols Source: W3C Copyright © Siemens AG 2009. All rights reserved. Page 6 May 2009 Siemens IT Solutions and Services
  • About Web Services System Model WSDL document WS consumer WS provider Application WS SOAP messages WS Application logic stack stack logicWSDL: the manual for a Web service; defines its service contract and allows topublish it in a documentWS-stack: the protocol engine for a Web service Provide SOAP message exchange esp. SOAP header processing including the SOAP security headers Also provide utilities for the publication of business functionality as Web service Well-known examples: Apache Axis, Microsoft WCF, Sun Metro Copyright © Siemens AG 2009. All rights reserved.Page 7 May 2009 Siemens IT Solutions and Services
  • About Web ServicesWeb Service Contracts (WSDL) Provide declarative descriptions for the functionality of a Web service esp.: Business functionality: Messages: which vocabulary is spoken by the Web service? Operations: which operations does it offer? Bindings: how to integrate with the underlying protocol stack? Ports: where to reach an endpoint of a Web service? Security functionality: User authentication: which objects (aka identity assertions) to provide in order to establish user authentication – including which attributes and other information to present? Message authentication: how to compute cryptographic checksums over request / response messages or parts thereof – including identity assertions? Message encryption: how to encrypt request/response messages or parts thereof – including identity assertions? Copyright © Siemens AG 2009. All rights reserved. Page 8 May 2009 Siemens IT Solutions and Services
  • About Web Services Security Token Services (WS-Trust) sp:Issued Token Are Web services that specialize on sp:Protection supplying certain security services esp. XML Document Token user authenticationWS consumer Provide a request/response framework for Application WS security token processing – issuance/ logic stack WS request/response validation/renewal/negotiation/cancellation STS request/response WS-stacks natively support: XML Document XML Document Acquisition of security tokens from STSs XML Document XML Document - triggered by WSDL child elements WS sp:IssuedToken stack STS XML Document Cryptographic binding of security tokens to SOAP messages - triggered by STS sp:ProtectionToken child elements logic As Web services, STSs may require their own security tokens for authenticating and authorizing security token requests Identity store Copyright © Siemens AG 2009. All rights reserved. Page 9 May 2009 Siemens IT Solutions and Services
  • About Web Services WS-* Security Technologies Compass Provides msg authentication Allows publishing of XML Signature W3C standard SOAP Message Provides msg encryptionWS-Policy WS-SecurityPolicy Security W3C OASIS standard OASIS standard standard (WS-SX TC) (WSS TC) Defines security Allows profiling of Provides user XML Encryption for STSs W3C standard authentication Defines WSs for managing WS-Trust Security token <Abstract> OASIS standard (WS-SX TC) Is a kind of Is an extension to SAML assertion WSFED OASIS standard OASIS committee (SAML TC) specification Copyright © Siemens AG 2009. All rights reserved. Page 10 May 2009 Siemens IT Solutions and Services
  • About Web ServicesRequirements On Identity Federation Solutions Stay in the Web services model i.e.: Request the supply of identity assertions as well as their SOAP message binding as a part of the WSDL Rationale: declarative description of service interfaces incl. security Supply identity assertions with SOAP message, esp. their headers Rationale: decoupling of business and security functionality Perform proof-of-possession for identity assertions by binding them with SOAP message contents Rationale: security Deliver security functionality such as user authentication in the form factor of a Web service Rationale: decoupling, separation of concerns Copyright © Siemens AG 2009. All rights reserved. Page 11 May 2009 Siemens IT Solutions and Services
  • Good NewsMain Aspect#1: Web Services Do It Natively Expressiveness requirements: Request identity assertions: the Web service contract allows to articulate requirements on identity assertions (WS-SecurityPolicy, WS-Trust): Whom to ask for the identity assertion? What to imprint into the identity assertion? How to secure it (proof-of-possession)? Supply identity assertions: WS-stacks natively acquire identity assertions (triggered by WS-SecurityPolicy sections in WSDLs; governed by WS-Trust) STSs provide native Web service abstractions dedicated to the issuance of identity assertions (defined by WS-Trust) WS-stacks natively transfer identity assertions within SOAP headers (triggered by WS-SecurityPolicy sections in WSDLs; governed by the SAML token profile of SOAP message security) Security requirements: Proof-of-possession (for identity assertions): WS-stacks natively support the cryptographic binding of identity assertions to SOAP messages (triggered by WS- SecurityPolicy sections in WSDLs; governed by the SAML token profile of SOAP message security) Copyright © Siemens AG 2009. All rights reserved. Page 12 May 2009 Siemens IT Solutions and Services
  • Good NewsMain Aspect#2: Has a Common-Sense Solution saml:Assertion objects present the common-sense solution for asserting identity in Web services environments. Copyright © Siemens AG 2009. All rights reserved. Page 13 May 2009 Siemens IT Solutions and Services
  • Good NewsUse Case Coverage The native Web services functionality covers the basic SSO use case in identity federation characterized by: Singular identity assertion per SOAP request Cleartext subject identifiers e.g. X.500 distinguished names, RFC 822 names (i.e. static information from persistence) User-centric subject attributes e.g. organizational affiliation or role assignments Copyright © Siemens AG 2009. All rights reserved. Page 14 May 2009 Siemens IT Solutions and Services
  • But Things Complicate QuicklyMore Sophisticated Use Cases But the native support does not cover more sophisticated SSO use cases and other identity federation use cases e.g.: Supply of multiple assertions per request e.g. WSs that ask for security tokens from multiple STSs Pseudonyms as privacy-preserving user identifiers Embodiment of subject-related authorization decisions or policies in identity assertions Commonly quoted options to choose identity federation protocols for more sophisticated use cases in Web services environments include: SAML 2.0 WS-Federation - generation 1 WS-Federation - generation 2 Liberty Alliance ID-WSF Liberty Alliance ID-SIS XSPA Copyright © Siemens AG 2009. All rights reserved. Page 15 May 2009 Siemens IT Solutions and Services
  • But Things Complicate QuicklyBrief Assessment SAML 2.0 WS-Federation WS-Federation Liberty Alliance Liberty Alliance XSPA generation 1 generation 2 ID-WSF ID-SISDeliverables Specifies identity assertions (for Specifies identity Specifies identity Defines a framework for Defines particular Adds access control arbitrary environments). Defines federation primitives federation primitives - building identity-based identity-based services: model to basic SSO use protocols, bindings and profiles - beyond SSO beyond SSO services employee profile, case. The considered for identity federation (mainly for personal profile, geo- authz model is health- Web applications) location, presence, care and RBAC specific contact bookUse cases SSO, SLO, name identifier SLO, attribute SLO, attribute/authz Authn, SSO, identity N.a. (no federation- Profiles standard mapping/management, service, pseudonym service, pseudonym mapping, permission-based enabler) abstractions according attribute/authz service service (note: SSO is service (note: SSO is attribute sharing, identity given objective natively covered) natively covered) service description and discoveryIdentity saml:Assertion Arbitrary security Arbitrary security saml:Assertion (produced N.a. (no federation- saml:Assertionassertion token including but token including but by the ID-WSF SSO enabler)form-factors not limited to not limited to service) saml:Assertion saml:AssertionExpressiven AuthnRequest is NameID and Inherits WS-Trust Inherits WS-Trust Builds upon SAML N.a. (no federation- Profiles standardess AuthnContext-centric: can not RST/RSTR and RST/RSTR and AuthnRequest/ Response enabler) abstractions according express expectations re assigned extends it according extends it according i.e. those parts of the given objective attributes and authz information. given use cases given use cases SAML specification suite AuthnRequest is also Web that are Web services service security unaware: can not unaware and builds own express expectations re binding solutions around the of identity assertions with SOAP shortcommunings inherited messages. from this design decisionExtensibility SAML request and response Inherits WS-Trust Inherits WS-Trust Does not provide relevant N.a. (no federation- Profiles standard messages define generic RST/RSTR and RST/RSTR and extension points in self- enabler) abstractions according extension points extends it according extends it according defined vocabulary given objective given use cases given use casesWeb SAML-defined SOAP bindings Native Web service Native Web service Native Web service Native Web service Native Web serviceservices remain ‘naïve’: empty specification specification specification specification specificationintegration soap:Header, Web service security unaware, no WSDLStandard OASIS standard Published vendor Emerging OASIS Liberty Alliance standard Liberty Alliance standard Emerging OASIS specification standard standard Copyright © Siemens AG 2009. All rights reserved. Page 16 May 2009 Siemens IT Solutions and Services
  • But Things Complicate QuicklyWeb Services Fitness of SAML 2.0 Usage with traditional Usage with Web applications Web services Inherit Web service security unawareness of the SAML bindings Web service security unaware • Request primitives do not help much (cf. below) • Query primitives present candidates Copyright © Siemens AG 2009. All rights reserved. Page 17 May 2009 Siemens IT Solutions and Services
  • But Things Complicate QuicklyLimitations of samlp:AuthnRequest Does mean „perform authn and provide report in the form of a saml:Assertion“ Among the main subsections in saml:Assertion objects it allows to express expectations on saml:Subject and saml:AuthnStatement Does not allow to express expectations on the saml:AttributeStatement subsection – this ability is key for claims-based approaches Web services use sp:RequestSecurityTokenTemplate which allows to shape the saml:AttributeStatement section (via wst:Claims child elements) Does not cover the proof-of-possession – this ability is key to advanced security models. Note that this requires To trigger the imprinting of certain information in the assertion Web services use abstractions such as wst:Entropy, wst:KeyType, wst:KeySize To trigger the cryptographic binding with the SOAP request Web services use various binding mechanisms Does not allow to request security tokens that are no SAML assertions – this ability is key for a holistic modeling (e.g. initial authn steps based on x509:Certificate objects and subsequent authn steps based on saml:Assertion objects) Copyright © Siemens AG 2009. All rights reserved. Page 18 May 2009 Siemens IT Solutions and Services
  • But Things Complicate QuicklyAlso Expect Difficulties Beyond The Specifications Following aspects do stress the features of currently available WS-stacks: Supply of multiple security tokens resp. identity assertions per WS request resp. transfer and handling of SAML assertion chains Supply of user-specific arguments in security token requests Handling of SAML assertions that embody subject-related authorization decisions or policies e.g. XACML policies Recommendation: select WS-stacks with care the more sophisticated an identity federation architecture gets. Copyright © Siemens AG 2009. All rights reserved. Page 19 May 2009 Siemens IT Solutions and Services
  • ConclusionsWeb Services Vs. Traditional Web Applications Dedicated, client-understood abstractions to request identity assertions: Web services use WS-SecurityPolicy sections in WSDLs Web applications do not have similar means and depends on workarounds for this limitation (SAML profiles, Shibboleth, Liberty Alliance ID-FF) or do implicitly invoke WS clients (CardSpace) Dedicated service abstractions for issuing identity assertions: Web services build upon STSs (WS-Trust) Web applications build upon specific abstractions that are defined by and confined to specific federation protocol technologies (e.g. SAML profiles, Shibboleth, Liberty Alliance ID-FF) Dedicated protocol layer for securely supplying identity assertions Web services have the SOAP message header layer and its security headers (SOAP message security, SAML token profile) and can esp. care about proof-of- possession Web applications do not have that and use the HTML layer as a replacement. They can not care about proof-of-possession because browsers are unaware of the identity assertion abstraction Copyright © Siemens AG 2009. All rights reserved. Page 20 May 2009 Siemens IT Solutions and Services
  • ConclusionsTechnology Options Web services natively support the basic SSO use case in identity federation: If your requirements match the basic SSO use case, there is no need to worry about complementary specifications such as WS-Federation, ID-WSF, ID-SIS, XSPA… Beware of false friends: WS-Federation is no prerequisite for Web services federation If your requirements go beyond basic SSO, there is not yet a silver bullet: Whether WS-Federation, ID-WSF, ID-SIS or XSPA do help, needs to be determined according the specific case Technology should follow use case: don‘t choose by (presumed) technology preference; choose by needs of your use case Check whether suggested solutions stay in the Web services model SAML vs. WS-* discussions are frequently encountered but are actually voodoo: there is a continental divide - you either have a Web application or a Web service: If you have a Web application, the SAML 2.0 specification suite will be a top candidate for an identity federation solution If you have a Web service, the SAML 2.0 specification suite will contribute the saml:Assertion abstraction but hardly much more Copyright © Siemens AG 2009. All rights reserved. Page 21 May 2009 Siemens IT Solutions and Services
  • OutlookThe discussed approach ‘First authenticate, then transfer authenticated subjectinformation’ presents a new paradigm for IdM in distributed systems. This isbreaking with the traditional tight coupling between producers (e.g. authentication)and consumers (e.g. authorization) of authenticated subject information.Expect this paradigm shift to happen – may be slowly, but steadily: Web services re-prioritize the paradigms for IdM in distributed systems: The emerging paradigm ‘First authenticate, then transfer authenticated subject information’ becomes the default approach. The traditional paradigm ‘First transfer unauthenticated user data, then authenticate’ becomes an exception. Other market participants sing the same song (cf. Microsoft Geneva, IdM and SOA whitepapers of various vendors) - just in other words Copyright © Siemens AG 2009. All rights reserved.Page 22 May 2009 Siemens IT Solutions and Services
  • AbbreviationsID-FF – Identity Federation FrameworkID-SIS - Identity Service Interface SpecificationsID-WSF - Identity Web Services FrameworkIdM – Identity ManagementRST – Request Security TokenRSTR – Request Security Token ResponseSAML – Security Assertion Markup LanguageSLO – Single Log OutSOAP – Simple Object Access ProtocolSSO – Single Sign OnSTS – Security Token ServiceW3C – World Wide Web ConsortiumWS – Web ServiceWSDL - Web Services Description LanguageXSPA - Cross-Enterprise Security and Privacy Authorization Copyright © Siemens AG 2009. All rights reserved.Page 23 May 2009 Siemens IT Solutions and Services
  • Namespace Prefixessaml – SAML (assertion syntax)samlp – SAML (protocol syntax)sp – WS-SecurityPolicywsp – WS-Policywst – WS-Trust Copyright © Siemens AG 2009. All rights reserved.Page 24 May 2009 Siemens IT Solutions and Services
  • AuthorDr. Oliver PfaffSiemens IT Solutions and ServicesE-Mail: oliver.pfaff@siemens.com Copyright © Siemens AG 2009. All rights reserved. Page 25 May 2009 Siemens IT Solutions and Services