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

Requestor

ClaimsSecurity tokensPolicy

Security Token Service

Web service ClaimsSecurity tokensPolicy

ClaimsSecurity tokensPolicy

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 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

HTTP

Liberty ID-FF WS-Federation

SAML 1.1 WS-Trust

WS-Security

SOAP

SAML 2.0

Shibboleth

Integrated with Liberty specifications and the result is SAML 2.0, which OASIS ratified in March 2006. Backed by multiple vendors (IBM, BEA, ..)

Backed by Microsoft

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 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

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