Transcript T-110.455 Network Application Frameworks and XML Web

T-110.5140 Network Application
Frameworks and XML
Service Federation
30.04.2007
Sasu Tarkoma
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?
Web services trust model
Security Token Service
Claims
Security
tokens
Policy
Requestor
Claims
Security
tokens
Policy
Web service
Claims
Security
tokens
Policy
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
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?
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
Delegation
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)
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
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
ID-FF specs

Liberty ID-FF



Liberty ID-WSF



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
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.
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
http://shibboleth.internet2.edu/
Putting it together so far
Integrated with Liberty specifications
and the result is SAML 2.0, which
OASIS ratified in March 2006. 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
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
Trust Federation

Federation servers





Maintain trust (keys)
Security (required assertions)
Privacy (allowed assertions)
Auditing (identities, authorizations)
Based on WS-Federation
Passport

Intended to solve two problems



First goal






over 250 million active Passport accounts and
1 billion authentications per day
Second goal


to be an identity provider to MSN
identity provider for the Internet
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
Identities

CardSpace (Microsoft)






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-*
http://www.identityblog.com/
IdentityCard
Source: http://www.identityblog.com/
Summary

We are going towards identity-based
access




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