T Network Application Frameworks and XML Service Federation Sasu Tarkoma

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

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

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

WS-Federation n How to establish trust between security token services (or identity providers) n Goal: use security tokens to realize seamless service access in different domains n Builds on WS-* specifications n WS-trust u Request a security token n WS-policy u Describe and acquire metadata u Grammar for requirements and capabilities u 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 Sign out notification sent to members of the federation n Special messages to request and cancel sign out messages (subject to policies) n Idempotent and unreliable n Special SOAP message n Clean any cached state and security tokens in the federation n Implication for active transactions not specified (resource specific)

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

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

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

Shibboleth n The Shibboleth software implements the OASIS SAML v1.1 specification, providing a federated Single-Sign-On and attribute exchange framework. n 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. n Using Shibboleth-enabled access simplifies management of identity and access permissions for both Identity and Service Providers. n An open-standard authentication system used by universities and the research community n Released under the Apache Software License. n Shibboleth 2.0 is basically equivalent to ID-FF through SAML 2.0 support n Integrates with Microsoft ADFS n

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

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

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

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

Identities n CardSpace (Microsoft) u Multiple identities u Interface for identity based authentication and authorization u Identity cards that people can choose u Integration with Web sites u Consistent user interface u Microsoft plans to implement this F ActiveX, WS-* n

IdentityCard Source:

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