State-of-the-Art in Web Services Federation

State-of-the-Art in Web
Services Federation

European Identity Conference 2009
Dr. Oliver Pfaff

Copyright © Siemens AG 2009. All rights reserved.

What’s Next?
Dive deeper into identity federation for Web services
Key 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

Page 2 May 2009 Siemens IT Solutions and Services

Setting the Scene
Reminder: A ‘Simple’ Trick Needs To Be Done

Resource provider
User
Request identity
assertions
Authorization
Supply identity
assertions Resource

Authentication

User data

Identity provider


Setting the Scene
Main 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’


Setting the Scene
Main Aspect#2: Asserting Identity
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
Authentication (of identity assertions): verify the authenticity of identity assertions


About Web Services
Defining 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


About Web Services
System Model
WSDL document
WS consumer WS provider

Application WS SOAP messages WS Application
logic stack stack logic

WSDL: the manual for a Web service; defines its service contract and allows to
publish it in a document
WS-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


About Web Services
Web 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?


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

About Web Services
WS-* Security Technologies Compass
Provides msg authentication
Allows publishing of
XML Signature
W3C standard
SOAP Message Provides msg encryption
WS-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


About Web Services
Requirements 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


Good News
Main Aspect#1: Web Services Do It Natively
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)
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.

Good News
Main Aspect#2: Has a Common-Sense Solution
saml:Assertion objects present the common-sense solution for asserting
identity in Web services environments.


Good News
Use 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


But Things Complicate Quickly
More 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


Brief Assessment
SAML 2.0 WS-Federation WS-Federation Liberty Alliance Liberty Alliance XSPA
generation 1 generation 2 ID-WSF ID-SIS
Deliverables 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 book
Use 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
discovery
Identity saml:Assertion Arbitrary security Arbitrary security saml:Assertion (produced N.a. (no federation- saml:Assertion
assertion token including but token including but by the ID-WSF SSO enabler)
form-factors not limited to not limited to service)
saml:Assertion saml:Assertion
Expressiven AuthnRequest is NameID and Inherits WS-Trust Inherits WS-Trust Builds upon SAML N.a. (no federation- Profiles standard
ess 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 decision
Extensibility 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 cases
Web SAML-defined SOAP bindings Native Web service Native Web service Native Web service Native Web service Native Web service
services remain ‘naïve’: empty specification specification specification specification specification
integration soap:Header, Web service
security unaware, no WSDL
Standard OASIS standard Published vendor Emerging OASIS Liberty Alliance standard Liberty Alliance standard Emerging OASIS
specification standard standard

Web 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


Limitations 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)

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


Conclusions
Web 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

Conclusions
Technology 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


Outlook
The discussed approach ‘First authenticate, then transfer authenticated subject
information’ presents a new paradigm for IdM in distributed systems. This is
breaking 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


Abbreviations
ID-FF – Identity Federation Framework
ID-SIS - Identity Service Interface Specifications
ID-WSF - Identity Web Services Framework
IdM – Identity Management
RST – Request Security Token
RSTR – Request Security Token Response
SAML – Security Assertion Markup Language
SLO – Single Log Out
SOAP – Simple Object Access Protocol
SSO – Single Sign On
STS – Security Token Service
W3C – World Wide Web Consortium
WS – Web Service
WSDL - Web Services Description Language
XSPA - Cross-Enterprise Security and Privacy Authorization

Namespace Prefixes
saml – SAML (assertion syntax)
samlp – SAML (protocol syntax)
sp – WS-SecurityPolicy
wsp – WS-Policy
wst – WS-Trust


Author
Dr. Oliver Pfaff
Siemens IT Solutions and Services
E-Mail: oliver.pfaff@siemens.com


State-of-the-Art in Web Services Federation

Recommended

Recommended

More Related Content

What's hot

What's hot (14)

Similar to State-of-the-Art in Web Services Federation

Similar to State-of-the-Art in Web Services Federation (20)

More from Oliver Pfaff

More from Oliver Pfaff (16)

Recently uploaded

Recently uploaded (20)

State-of-the-Art in Web Services Federation

Editor's Notes