1. T-110.5140 Network Application Frameworks and XML Service Federation 25.04.2006 Sasu Tarkoma

2. Introduction
How to combine and use services in different security domains?
How to take into account privacy aspects?
How to enable single sign on (SSO) for users?

3. Web services trust model
Security Token Service
Claims
Security tokens
Policy
Requestor
Web service
Claims
Security tokens
Policy
Claims
Security tokens
Policy

4. WS-Trust
Methods for issuing, renewing, and validating security tokens.
Ways to establish, assess the presence of, and broker trust relationships
Messages for
Requesting security tokens from a security token service (STS)
Renewal of tokens
Cancel binding
Validation
Extensions for forwarding and delegation

5. WS-Federation
How to establish trust between security token services (or identity providers)
Goal: use security tokens to realize seamless service access in different domains
Builds on WS-* specifications
WS-trust
Request a security token
WS-policy
Describe and acquire metadata
Grammar for requirements and capabilities
Practical concern: minimum crypto? Do participants support same security mechanisms?

7. Federation Sequence Diagram
Requestor
SRC STS
DST STS
Web service
Request token
Issue token
Request token with token reference
Issue token from DST domain
Send request (+token) to service
Validate token
Approve token
Return value

9. Delegation

10. Federated Sign-out
Sign out notification sent to members of the federation
Special messages to request and cancel sign out messages (subject to policies)
Idempotent and unreliable
Special SOAP message
Clean any cached state and security tokens in the federation
Implication for active transactions not specified (resource specific)

11. Pseudonyms Support for pseudonyms (optional)
A resource does not need necessarily to know the true identity of a requestor
Authorization is required and relevant attributes for personalization
Authorized services can query these attributes
Messages for getting/setting/deleting pseudonyms

12. OMA ID-FF Liberty Alliance Identity Federation Framework (ID-FF)
Basic case: Web direction
Mandatory features for an identity provider
Single sign on and federation
Single sign out
Federation termination
Affliliations
Dynamic proxying of Identity Providers
Circle of trust implemented using
SAML assertions, requests, redirection, and validation

13. ID-FF specs Liberty ID-FF Liberty ID-WSF Liberty ID-SIS
Identity Federation Framework
A forerunner to the SAML 2.0 specification. All of the functionality in ID-FF has been incorporated into SAML 2.0
Liberty ID-WSF
Identity Web Services Framework
Builds on WS-Security and SAML 2.0
Liberty ID-SIS
Identity Services Interface Specifications
High-level web service interfaces that support particular use cases like data/profile, geolocation, contact book, and presence services.

14. Shibboleth
The Shibboleth software implements the OASIS SAML v1.1 specification, providing a federated Single-Sign-On and attribute exchange framework.
Shibboleth also provides extended privacy functionality allowing the browser user and their home site to control the Attribute information being released to each Service Provider.
Using Shibboleth-enabled access simplifies management of identity and access permissions for both Identity and Service Providers.
An open-standard authentication system used by universities and the research community
Released under the Apache Software License.
Shibboleth 2.0 is basically equivalent to ID-FF through SAML 2.0 support
Integrates with Microsoft ADFS

15. Putting it together so far
Integrated with Liberty specifications and the result is SAML 2.0, which OASIS ratified in March Backed by multiple vendors (IBM, BEA, ..)
SAML 2.0
Shibboleth
Liberty ID-FF
WS-Federation
Backed by Microsoft
SAML 1.1
WS-Trust
WS-Security
HTTP
SOAP

16. Active Directory Active Directory Federation Services (ADFS)
Windows Server 2003
Web SSO (single sign-on)
Identity federation
Distributed web-SSO
SSO for IISv6 web farms
Security tokens & assertions
Assertions on security principals
Security token service grants tokens
Possession of private key is proof of identity

17. Trust Federation Federation servers Based on WS-Federation
Maintain trust (keys)
Security (required assertions)
Privacy (allowed assertions)
Auditing (identities, authorizations)
Based on WS-Federation

18. Passport Intended to solve two problems First goal Second goal
to be an identity provider to MSN
identity provider for the Internet
First goal
over 250 million active Passport accounts and
1 billion authentications per day
Second goal
What is the role of the identity provider in transactions?
Passport no longer stores personal information other than username/password credentials
Authentication service for sites
Proprietary technology
Roadmap: towards identity card

19. Identities InfoCard (Microsoft) http://www.identityblog.com/
Multiple identities
Interface for identity based authentication and authorization
Identity cards that people can choose
Integration with Web sites
Consistent user interface
Microsoft plans to implement this
ActiveX, WS-*

20. IdentityCard
Source:

21. Summary We are going towards identity-based access Challenges
A number of identities per host
Pseudonyms, privacy issues
Delegation and federation are needed
SAML 2.0 is a key specification in representing assertions and provides a baseline for interoperability
ID-FF, Shibboleth, ADFS
Challenges
Automatic configuration of policies
Logging and auditing