More Related Content Similar to State-of-the-Art in Web Services Federation (20) More from Oliver Pfaff (16) State-of-the-Art in Web Services Federation2. 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
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 2 May 2009 Siemens IT Solutions and Services
3. 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
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 3 May 2009 Siemens IT Solutions and Services
4. 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ā
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 4 May 2009 Siemens IT Solutions and Services
5. Setting the Scene
Main 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
6. 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
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 6 May 2009 Siemens IT Solutions and Services
7. 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
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 7 May 2009 Siemens IT Solutions and Services
8. 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?
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 8 May 2009 Siemens IT Solutions and Services
9. 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.
Page 9 May 2009 Siemens IT Solutions and Services
10. 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
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 10 May 2009 Siemens IT Solutions and Services
11. 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
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 11 May 2009 Siemens IT Solutions and Services
12. Good News
Main 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
13. 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.
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 13 May 2009 Siemens IT Solutions and Services
14. 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
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 14 May 2009 Siemens IT Solutions and Services
15. 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
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 15 May 2009 Siemens IT Solutions and Services
16. But Things Complicate Quickly
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
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 16 May 2009 Siemens IT Solutions and Services
17. But Things Complicate Quickly
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
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 17 May 2009 Siemens IT Solutions and Services
18. But Things Complicate Quickly
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)
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 18 May 2009 Siemens IT Solutions and Services
19. But Things Complicate Quickly
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.
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 19 May 2009 Siemens IT Solutions and Services
20. 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
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 20 May 2009 Siemens IT Solutions and Services
21. 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
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 21 May 2009 Siemens IT Solutions and Services
22. 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
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 22 May 2009 Siemens IT Solutions and Services
23. 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
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 23 May 2009 Siemens IT Solutions and Services
24. Namespace Prefixes
saml ā SAML (assertion syntax)
samlp ā SAML (protocol syntax)
sp ā WS-SecurityPolicy
wsp ā WS-Policy
wst ā WS-Trust
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 24 May 2009 Siemens IT Solutions and Services
25. Author
Dr. Oliver Pfaff
Siemens IT Solutions and Services
E-Mail: oliver.pfaff@siemens.com
Copyright Ā© Siemens AG 2009. All rights reserved.
Page 25 May 2009 Siemens IT Solutions and Services
Editor's Notes 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.