WS-Federation

Jim Van Dyke Zhengping Wu

Partially adapted from workshop slides by Tony Nadalin (IBM) and Chris Kaler (Microsoft)
 Agenda
 Introduction
 Trust Topologies
 Single Sign-out
 Attribute Services
 Pseudonym Services
 Active/Passive Profiles
 Summary and Conclusions
 Demo
 References
2
 What is Federation?
 Federation
 A collection of realms/domains that have
established trust
 The technology and business arrangements
necessary to interconnect users, applications,
and systems
 Federated systems can interoperate across
organizational and technical boundaries (i.e.,
various operating systems or security
platforms)
3
Federated ATM Network

Account Number
and PIN Visiting Bank Network

Funds Network of Trust

Home Bank Network

4
 WS-Federation
 Primary Goal: “Single Sign-On” access
across trust domains using identities from
the different domains
 WS-Federation defines a model for this by
building on the WS-* security
specifications:
 Brokering trust
 Sign out messages
 Attribute service
 Pseudonym service
5
 WS-Federation Terms
 Authorities
 Security Token Service (STS) – Web service that issues
security tokens; makes assertions based on evidence
that it trusts to whoever trusts it
 Identity Provider (IP) – Entity that acts as an
authentication service to end requestors (an extension
of a basic STS)

 Principles
 Requestor
 Resource
 Other Services 6
 One Protocol, Multiple Bindings
 Common protocol (WS-Trust)
 Two “profiles” of the model are defined
 Smart/Active clients (SOAP)
 Passive clients (Browser – HTTP/S)
 Supporting services (attribute/pseudonym/…)

HTTP messages HTTP Security

Receiver
SOAP
Token
SOAP messages Receiver Service
7
 Trust Topologies
 Federation approach must address
different trust topologies
 Model existing business practices
 Leverage existing infrastructure

 Sample topologies
 Direct trust
 Exchange
 Validation
 Indirect trust
 Delegation 8
 Direct Trust
Token Exchange
IP/STS IP/STS

Trust

Get access
Get identity 1
token
token 2 Resource

Requestor

9
 Direct Trust Flow
Requestor Requestor WS Service
Service IP/STS Service IP/STS
Acquire policy
Return policy
Request token

Return token

Request token

Return token

Send secured request

Return result
10
 Direct Trust
Token Validation
IP/STS IP/STS
Trust

Get identity Get access

1 3
token verification
Requestor Resource

11
 Indirect Trust
IP/STS

IP/STS
B IP/STS

A C

1
2
Requestor Resource

C trusts B which vouches for A who vouches for client 12

 Delegation
IP/STS IP/STS IP/STS

Trust Trust

1 2 4

Resource Resource

3 5

Requestor
13
 Single Sign-Out
IP/STS

…
Requestor IP/STS
2

1 2 …
2

Resource

14
 Sign-Out Message
<S:Envelope>
<S:Header>
...
<wsu:Timestamp wsu:Id="ts">
... </wsu:Timestamp>
<wsse:Security>
<!-- Signature referecing IDs "ts" & "so" -->
...
</wsse:Security>
</S:Header>

15
 Sign-Out Message (cont.)
<S:Body>
<wsse:SignOut wsu:Id="so">
<wsse:SignOutBasis>
<wsse:UsernameToken>
<wsse:Username>NNK</wsse:Username>
</wsse:UsernameToken>
</wsse:SignOutBasis>
</wsse:SignOut>
</S:Body>
</S:Envelope>

16
 Requesting Sign-Out Message
<wsse:RequestSSOMessages>
<wsa:EndpointReference>
<wsa:Reference>http://business456.com/SSO
</wsa:Reference>
</wsa:EndpointReference>
<wsse:UsernameToken>
<wsse:Username>Nicholas</wsse:Username>
</wsse:UsernameToken>
</wsee:RequestSSOMessages>

17
 Attribute Service
 Scenario: You ask a weather service for the
current weather (or visit a weather site); it
provides a personalized response because it
knows your zip code

 Why it worked:
 Policy indicated an attribute service
 Identity information was used to find zip code
 Weather service was authorized to access zip code
(opt-in)

 Specification defines the concept of an attribute

service but not a specific interface 18
 Attribute Service Example

 Attributes may have associated scopes

 Each attribute may have its own access control and
privacy policy 19
 Attribute Scoping

Zip: 12309
FN: Fred
ID: 3442
(fabrikam123.com)
Nick: Freddo
ID: FJ454 (business456.com)
Nick: Fredster
ID: 3-55-34 (example.com)
…

Model allows for attributes to be scoped

20
 Attribute Discovery
 Open design model
 Any attribute store can be used
 Integration with legacy systems
 Discovery via policy
 Requestor’s policy  attribute service
 Attribute service has its own policy
 Communication is governed by this policy
 UDDI is an example store
21
 Attribute Discovery
Attribute
Service
3

Policy
2
Policy 4
“Get FN”
Requestor
Resource

22
 Attribute Example Attribute
Service
IP/STS IP/STS

Trust Trust

Zip: 12309
1 4 FN: Fred
2
…

Requestor Resource
23
 Protecting Identity
 Single sign-on also needs to
 Prevent identity tracking
 Provide anonymity

 Other forms of identity tracking still exist:

 Address
 Phone number
 Credit card
 Social security number
24
 Identity Approaches

 One federation model

 Multiple identity approaches

 Static identifier, possibly obfuscated
 Static per-target identifier
 One-time identifier

25
 Static Identifier Example
IP/STS

“Fred” 
1
“Fred@STS”
Resource

Requestor

“Fred@STS”
26
 Static Per-Target Example
IP/STS

“Fred”  “Fred” 
1 3
“A123” “B456”
Resource Resource

2 4

“A123” “B456”
Requestor
27
 Pseudonym Service

 This service provides a mechanism for

associating alternate identities

 Pseudonyms represent alternate

identities
 Depends on scope of request
 Subject to authorization control
 Can be integrated with IP/STS
28
 Pseudonym Discovery
Pseudonym
Service 3

Policy
4
2
Policy

Requestor
Resource

29
 Pseudonym Example 1
B456.com B456.com
Pseudonym
IP Trust Service

“Fred” 
“A123@B456.com” “A123@B456.com” 
1 3 “Freddo@F123.com”

Requestor
Resource
2

“A123@B456.com”

 Service sets pseudonym for its domain 30

 Pseudonym Example 2
B456.com B456.com
Pseudonym
IP Trust Service

“Fred”  “B456@B456.com” 
“B456@B456.com” “Freddo@F123.com”
1 3 4

Requestor
Resource
2

“B456@B456.com”

 Service fetches pseudonym for its domain 31

 Pseudonym/STS Integration

Token
Request

 Pseudonym & STS can work together

 Single physical service
 Separate but tightly coupled services
32
 Pseudonym Example 3
B456.com B456.com
Pseudonym
IP Trust Service

2
“Fred” 
“Freddo@F123.com” “Fred”  “Freddo@F123.com”
1

Requestor Resource

“Freddo@F123.com”

 Use pseudonyms to obtain initial token 33

 Active (Smart Client) Profile
 Describes options for SOAP-enabled
clients
 Varied models based on policy
 Business needs
 Inter-organization relationships
 Regulations
 Strong authentication of all requests
34
 Example Flow (SOAP)
Requesting Requestor’s Target Target’s
Service IP/STS Service IP/STS

Acquire policy

Request token

Return token

Request token

Return token

Send secured request

Return secured response

35
 Passive Profile
 Describes options for browser clients
 URL-only
 GET, POST body
 Cookies (a custom caching mechanism)
 Uses redirection to effect messages

 Should conform as closely as possible

to WS-Trust protocols
36
 Example Flow (Browser)
Requesting Requestor’s Target Target’s
Browser IP/STS Resource IP/STS

Get resource

Redirect to resource’s IP/STS

Detect realm

Redirect to requestor’s IP/STS

Login

Return identity token

Return resource token

Return secured response 37

 WS-Federation
Features
 Cross-domain trust federation
 Generic token acquisition
 Enables different trust topologies
 Single Sign-On / Sign-Off
 Identity Protection and Privacy
 Attributes and Pseudonyms
 End-to-end security
 No HTTPS required 38
 WS-Federation
Summary
 Integrates with existing infrastructures
 Business model
 Token formats
 Attribute stores
 Directory services
 Together with the other WS-*
specifications, provides a rich fabric for
building secure, reliable, transacted
systems across federation boundaries
39
 Basic Trust Federation Demo
 3 Participants:
Client, Service, STS
 No trust relationship
between Client
(requestor) and
Service (resource)
 Client and Server
trust the STS
 Uses WSE 2.0: Supports WS-Security, WS-Policy,
WS-SecurityPolicy, WS-Trust,
WS-SecureConversation, and WS-Addressing. 40
Optional Extensions of Demo

Token Validation Mapping with WS-Addressing

41
 Primary References
 WS-Federation Feedback Workshop
 These workshop slides provide an overview of WS-
Federation.
http://www-
106.ibm.com/developerworks/offers/WS-
Specworkshops/ws-fed200311.html

 Federation of Identities in a Web Services World

 This whitepaper discusses using WS-Federation to
federate identities across trust domains.
http://msdn.microsoft.com/ws-federation/

42
 Secondary References
 Web Services Federation Language (WS-Federation)
 This is the complete WS-Federation specification.
http://msdn.microsoft.com/ws/2003/07/ws-federation/

 WS-Federation: Active Requestor Profile

 This is the specification for active profiles in WS-Federation.
http://msdn.microsoft.com/ws/2003/07/ws-active-profile/

 WS-Federation: Passive Requestor Profile

 This is the specification for passive profiles in WS-Federation.
http://msdn.microsoft.com/ws/2003/07/ws-passive-profile/

43