WS-Federation

Download Report

Transcript WS-Federation

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
Funds
Visiting Bank Network
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
SOAP messages
HTTP
Receiver
SOAP
Receiver
Security
Token
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 identity
token
1
Get access
token
2
Resource
Requestor
3
9
Direct Trust Flow
Requestor
Service
Requestor
IP/STS
WS
Service
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
token
1
3
Get access
verification
Resource
Requestor
2
11
Indirect Trust
IP/STS
B
IP/STS
IP/STS
A
C
1
2
Resource
Requestor
3
C trusts B which vouches for A who vouches for client
12
Delegation
IP/STS
IP/STS
1
IP/STS
Trust
Trust
2
4
Resource
3
Resource
5
Requestor
13
Single Sign-Out
IP/STS
…
Requestor
IP/STS
1
2
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
18
service but not a specific interface
Attribute Service Example


Attributes may have associated scopes
Each attribute may have its own access control and
19
privacy policy
Attribute Scoping
Zip: 12309
FN: Fred
ID: 3442
Nick: Freddo
ID: FJ454
Nick: Fredster
ID: 3-55-34
…
(fabrikam123.com)
(business456.com)
(example.com)
Model allows for attributes to be scoped
20
Attribute Discovery

Open design model



Discovery via policy




Any attribute store can be used
Integration with legacy systems
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
Policy
3
Attribute
Service
4
Requestor
Policy
2
“Get FN”
Resource
1
22
Attribute Example
IP/STS
Attribute
Service
IP/STS
Trust
1
Trust
4
2
Zip: 12309
FN: Fred
…
3
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” 
“Fred@STS”
1
Resource
Requestor
2
“Fred@STS”
26
Static Per-Target Example
IP/STS
“Fred” 
“A123”
1
3
“Fred” 
“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
Policy
3
4
Requestor
Policy
2
Resource
1
29
Pseudonym Example 1
B456.com
Pseudonym
Service
B456.com
IP
Trust
“Fred” 
“[email protected]” 
3 “[email protected]”
“[email protected]”
1
Requestor
Resource
2
“[email protected]”

Service sets pseudonym for its domain
30
Pseudonym Example 2
B456.com
Pseudonym
Service
B456.com
IP
“Fred” 
“[email protected]”
Trust
1
3
4
“[email protected]” 
“[email protected]”
Requestor
Resource
2
“[email protected]”

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
IP
Trust
B456.com
Pseudonym
Service
2
“Fred” 
“[email protected]”
“Fred”  “[email protected]”
1
Requestor
Resource
3
“[email protected]”

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
Service
Requestor’s
IP/STS
Target
Service
Target’s
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)
Requestor’s
IP/STS
Requesting
Browser
Target
Resource
Target’s
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



Single Sign-On / Sign-Off
Identity Protection and Privacy


Enables different trust topologies
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 WSFederation.
http://www106.ibm.com/developerworks/offers/WSSpecworkshops/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