T110 5140 Network Application Frameworks and XML Service

T-110. 5140 Network Application Frameworks and XML Service Federation 30. 04. 2007 Sasu Tarkoma

Introduction n 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 n n n Methods for issuing, renewing, and validating security tokens. Ways to establish, assess the presence of, and broker trust relationships Messages for u u n Requesting security tokens from a security token service (STS) Renewal of tokens Cancel binding Validation Extensions forwarding and delegation

WS-Federation n n 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 u n Request a security token WS-policy u u u 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 n n n 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 n n n 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 n n n Liberty Alliance Identity Federation Framework (ID-FF) Basic case: Web direction Mandatory features for an identity provider u u u n Single sign on and federation Single sign out Federation termination Affliliations Dynamic proxying of Identity Providers Circle of trust implemented using u SAML assertions, requests, redirection, and validation

ID-FF specs n Liberty ID-FF u u n Liberty ID-WSF u u n 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 u u Identity Services Interface Specifications High-level web service interfaces that support particular use cases like data/profile, geolocation, contact book, and presence services.

Shibboleth n n n n The Shibboleth software implements the OASIS SAML v 1. 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. internet 2. 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 n n Active Directory Federation Services (ADFS) Windows Server 2003 Web SSO (single sign-on) Identity federation u n n Distributed web-SSO for IISv 6 web farms Security tokens & assertions u u u Assertions on security principals Security token service grants tokens Possession of private key is proof of identity

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

Passport n Intended to solve two problems u u n First goal u u n n over 250 million active Passport accounts and 1 billion authentications per day Second goal u n 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 n Card. Space (Microsoft) u u u 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 F n Active. X, WS-* http: //www. identityblog. com/

Identity. Card Source: http: //www. identityblog. com/

Summary n We are going towards identity-based access u u 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 F n ID-FF, Shibboleth, ADFS Challenges u u Automatic configuration of policies Logging and auditing