T-110.5140 Network Application Frameworks and XML Service Federation 25.04.2006 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 Web service Claims Security tokens Policy 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 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.

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 Based on WS-Federation Maintain trust (keys) Security (required assertions) Privacy (allowed assertions) Auditing (identities, authorizations) Based on WS-Federation

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

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-* http://www.identityblog.com/

IdentityCard Source: http://www.identityblog.com/

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