Transcript Lecture on Federated Security Can delegated trust work? Walter Kriha Overview • Why we need federated trust? Direct trust does not scale in distributed systems •

Lecture on
Federated Security
Can delegated trust work?
Walter Kriha
Overview
• Why we need federated trust? Direct trust does not
scale in distributed systems
• What makes federated trust secure? Leveraging
high quality direct trust relations and delegation of
authority
• Cross-Domain Trust between infrastructures
• Web-SSO Architectures
• Identity and Federation in Social Networks
(Facebook etc.)
Super-Hub Architecture
Direct trust does not
scale!
Ways to combine registries
Meta Directory
Virtual Directory
Federated Identities
Service
Interface
META
Registry
copy and replicate
dynamically pull
User
User
User
User
Registry
Registry
Registry
Registry
Consistency? Name
clashes? Privacy?
Politics and
Economics?
Performance?
Name clashes?
Privacy? Politics
and Economics?
User
User
Registry
Registry
exchange metadata on
users. Allow aliases to
protect users. Do not
expose login credentials
Trust? Control?
QoS?
Federated Visa Card System
Dealer
Present
card
Customer
Request
payment
Issue
card
clearing
Card Issuing
Bank
Dealers Bank
Visa
„Outsourcing“ of Trust Establishment
Present request and
Proof of Identity
Token
Present token
to establish
remote,
authenticated
session
Identity Provider
Return signed token
containing authentication
statement
Trust relation
to IP
Service Provider
Third Party Identity Assertion and Authorization
Log-in to SSO System
Request token for supplier
Company
Token
Employee
Return signed token containing
authentication statement and optionally
autorisation to order stuff from supplier
Present token to
prove work-relation
and optional
authority.
Trust relation
secured by
certificates
Supplier
Check signature of company. Knows now
a) employee really works for company
b) Employee is authorized to order (optional)
Why Third Party Trust is OK
• Does receiver really have a trust relation to employee of
the company?
• What does it mean for the receiver to give the foreign
employee a login name and credential?
• What happens if the employee
–
–
–
–
–
Changes job function?
Leaves the company?
Uses credentials a year later?
Starts buying non-authorized things?
Hands-over login credentials?
• How many login credentials does the employee need?
• How many times does she use them?
Federated Identity Management Across Domains
Token
Token
User
Customer
alias
Authent
Author.
Identity
Credent.
Server
Server
Server
Vault.
App.
CSIv2
client
Registry
Token
Reverse
Internet
Proxy
CSIv
2
External
WS-S
WS-S
Internet
Server
Internet
Point of
contact
TTP
Token
Domain
Bridge
(TTP)
Authentication
provider
Host
Token
Token
App.
Token
Server
Server
Token
CSIv2
App.
Customer
alias
App.
Server
Other Company
Infrastructure converter
GEN0190n.ppt
9
WS-Trust Server checking foreign Token
WS-Trust
Server
Token
Token
Web-based SSO Scenarios
•
•
•
•
Redirect Mechanism
Background communication
Where are you from
Privacy issues
Redirect of unauthenticated request to identity
provider: Pull Szenario
2.
Service Provider 1
Identity Provider
1.
3.
User
Re-redirect back to Service Provider
Service Provider
1
4.
5.
User
Identity Provider
Functional Extensions to simple Web-SSO
• WAYF (Where are you from): How can the service
provider know which STI the customer is using?
• Account Linking (SP and Customer are members of
several STIs/IPs)
• Size and content of token
• Different user agents and transport protocols (e.g. webservices)
Federative Extensions to simple Web-SSO
• Both Service Provider and IP run their own identity
management with separate user registries
• The customer is using several IPs
• The SP has several contract relations with other SPs
Redirect of authenticated user to selected SP
(Push Model)
Dynamic Menue:
„Clicked“ by
user
-Link to SP1
- Link to SP2
- Link to SP3
Service Provider
1
Identity Provider
User
Front-Channel vs. Back-Channel
Back channel communication for extended user information
Service Provider
1
Identity Provider
push mechanism
Pull mechanism
Random number or
extended user information
(SAML)
User
Front channel
Account linking with User Alias
User_X, PW_X, IP_Alias 123
X_User, PW_Z, IP_Alias 123
Back channel communication for automatic provisioning
Service Provider
1
Identity Provider
Allows mapping
between IP Alias
and own UserID for
user
Front channel
mapping
User
At IP: User_X, PW_X
At SP1: X_User, PW_Z
Secure Messages with „Active Profile“ – Web
Service enabled communication
2.
Service Provider 1
Identity
Provider, WSTrust Server
3.
1.
4.
5.
Web Service
Client
Application
Secure Association Markup Language (SAML)
•
•
•
•
•
•
•
Policy Expression Language
XML based language for secure statements (Assertions)
Elements like user, attributes, validity constraints, QoS etc.
Authentication Assertion
Attribute Assertion
Authority Assertion
Binding information about transport protocols, get/post
methods etc.
• Object/Message based security instead of only channel
based security
SAML Assertion (example)
<saml:Assertion Version="2.0„ ID="_34234se72„ IssueInstant="2005-04-01T16:58:33.173Z">
<saml:Issuer>http://authority.example.com/</saml:Issuer>
<ds:Signature>...</ds:Signature> <!– issuer signature 
<saml:Subject>
<saml:NameID format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
jygH5F90l
</saml:NameID>
</saml:Subject>
<saml:AuthnStatement AuthnInstant="2005-04-01T16:57:30.000Z">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>
From: [ANTON06]
SAML embedded in SOAP Header
<SOAP-ENV:Envelope> <!– SOAP Spec. 
<SOAP-ENV:Header>
<wsse:Security> <!– Web Services Security Spec. 
<saml:Assertion>user, authentication, issuer etc.
</saml:Assertion>
</wsse:Security>
</SOAP-ENV:Header>
<SOAP-ENV:Body>...
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
From: [ANTON06]
WS-Federation Active Profile Example
CompanyXYZ
SSO
login
Portal
TelCo Provider
Link with Forms Post to TelCo
Internal
STI
Conference
System
Own
Token
SPNEGO
TOKEN
User: XYZ_guest
CN: foo
Email: [email protected]
employee
Company: XYZ
User: foo
Email: [email protected]
Mapping of all employees to
ONE guest account for XYZ
at access manager of TelCo
SAML Assertion
in Token
ID and time of issued assertion,
namespaces galore
<saml:Assertion AssertionID="…„ IssueInstant="2007-03-20T12:30:50Z"
Issuer="https://www.xyz.com/wsf" MajorVersion="1„ MinorVersion="1„ xmlns:ds=http://www.w3.org/2000/09/xmldsig#
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
<saml:Conditions NotBefore="2005-07-16T15:14:29Z„ NotOnOrAfter="2005-07-16T15:34:29Z">
<saml:AudienceRestrictionCondition>
<saml:Audience>https://www.telco.com/wsf
</saml:Audience>
</saml:AudienceRestrictionCondition>
</saml:Conditions>
When is this
statement valid?
Who is the
<saml:AuthenticationStatement AuthenticationInstant="2005-07-16T15:24:29Z"
receiver?
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
<saml:Subject>
<saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
emp1@<xyz.com
</saml:NameIdentifier>
Who is
</saml:Subject>
authenticated?
</saml:AuthenticationStatement>
(subject)
<saml:AttributeStatement>
<saml:Subject>
<saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
[email protected]
</saml:NameIdentifier>
What attributes
</saml:Subject>
does subject have?
<saml:Attribute AttributeName="cn„ AttributeNamespace="http://www.xyz.com/cn">
<saml:AttributeValue>Employee One </saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
federation part of assertion – defines conditions,
authentication, subject and subject attributes
<ds:Signature Id="uuid203f1582-0105-efbb-6039-8ce3efd72411„ xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
How signature
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
was created
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#Assertion-uuid203f1557-0105-f23c-5b82-8ce3efd72411">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<xc14n:InclusiveNamespaces PrefixList="saml ds„ xmlns:xc14n="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue> sWS4qUyQXSgMRHM62ADxLHGfFD4=
</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue> signature over assertion (according to XMLDsig Spec.)...
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate> XYZ Corp. Certificate,......
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
</saml:Assertion>
Signature value to
Check against
Who did it: Signers
certificate so
receiver (telco)
can check
signature
Non-federation part of assertion – deals only
with message security of assertion statement
Identity and Federation in Social Networks
• The Tripartite Identity Pattern
• OpenID (Technology and the Nascar Problem)
• OAuth (Granular access delegation)
• XRD/JRD
Randy Farmer developed the above pattern which separates functions of IDs
along the dimensions of uniqueness and memorizablity. Account IDs are uniq
and can be of arbitrary complexity as they are used only for internal linking and
bookkeeping and are never exposed. Login IDs are critical because they need
to be both unique and easy to remember. Public IDs are not unique but should
be easy to remember. They need additional criteria for disambiguation
(pictures, friends, actions). The diagram is taken from „ Super Social
Everybody – how to survive in the social web“, Thomas Fankhauser, Stuttgart
Media University 2010
OpenID/OAuth
• The Password Anti-Pattern
• The Nascar Problem
• Acceptance and Problems
• Service Providers as Identity Provider
The Nascar Problem
Too many big labels/icons of identity providers (from:
http://factoryjoe.com/blog/2009/04/06/does-openid-need-to-be-hard/)
OAuth/WRAP
• Granular Token Generation for Mashups
• Message/API Signatures
• Simple Bearer Tokens
• The Question of Channel Security
Spec. At http://oauth.net/core/1.0a/, http://hueniverse.com/2010/05/introducing-oauth-2-0/
http://hueniverse.com/2010/01/open-questions-about-oauth-2-0-authentication/
http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/#comments
http://hueniverse.com/oauth/
OAuth Sequence Diagram
From: http://d.hatena.ne.jp/ZIGOROu/20090811/1250006392
Facebook Authorization Example
From: http://www.uml-diagrams.org/sequence-diagrams-examples.html
Security Analysis
•
•
•
•
•
•
•
•
•
Token Integrity and Confidentiality
Token Verification
Phising with bad redirect to phony IP
Customer confusion about credentials if both SP and IP
support their own identity management mechanisms
Privacy problems with Identity Provider
Log-out problem: Guarantees for customer?
Token abuse by SP?
Attack on tokens at client?
Session to IP?
Resources
[Anton] E. Anton, Web Services in realen Business-Anwendungen – Sicherheit,
Transaktionalität, Geschäftsprozess-Modellierung, Diplomarbeit HdM 2006,
http://www.kriha.de/krihaorg/dload/uni/anton.pdf
[EBR] J. Eisenmann, A. Rauber, S. Simon, Single Sin On, Software-Projekt
HdM 2003, http://www.kriha.de/krihaorg/dload/uni/
eisenmann_rauber_simon.zip
[Bueck] A. Buecker, W.Filip, H.Hinton, H.Hippenstiel, M.Hollin, R.Neucom,
S.Weeden, J.Westman, Federated Identity Management and Web Services
Security, IBM Redbook 2005
[End]
D. Endler, SessionID Hacking, http://www.idefense.com
[SAML] Security Assertion Markup Language(SAML) 2.0: Technical Overview.
2006, http://www.oasis-open.org/committees/download.php/20645/
sstc-saml-tech-overview-2%200-draft-10.pdf
[Wind] P. J. Windley, Digital Identity – unmasking Identity Management
Architecture (IMA), O’Reilly 2005
[WS-FED] H. Lockhart et al., Web Services Federation Language Version 1.1
(2006), http://www.ibm.com/developerworks/library/specification/ws-fed/
[WS-SEC] B. Atkinson et al.: Web Services Security (WS – Security),
http://www.ibm.com/developerworks/library/ws-secure