Federated Security

Can delegated trust work?

Lecture on

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!

User

Registry

User

Registry

META

Registry

User

Registry

User

Registry

User

Registry

User

Registry

ServiceInterface

dynamically pullcopy and replicate

exchange metadata on users. Allow aliases to protect users. Do not expose login credentials

Meta Directory Virtual Directory Federated Identities

Consistency? Name clashes? Privacy? Politics and Economics?

Performance? Name clashes? Privacy? Politics and Economics?

Trust? Control?

QoS?

Ways to combine registries

Card IssuingBank

Customer

Dealer

Dealers Bank

Visa

Issue card

Present card

Request payment

clearing

Federated Visa Card System

Identity Provider

Service Provider

Token

Present request and Proof of Identity

Present token to establish remote, authenticated session

Return signed token containing authentication statement

„Outsourcing“ of Trust Establishment

Trust relation to IP

Company

Supplier

Token

Log-in to SSO System

Present token to prove work-relation and optional authority.

Return signed token containing authentication statement and optionally autorisation to order stuff from supplier

Employee

Request token for supplier

Check signature of company. Knows now

a) employee really works for company

b) Employee is authorized to order (optional)

Trust relation secured by certificates

Third Party Identity Assertion and Authorization

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?

GEN0190n.ppt 9

Other Company

client

Internet

Internet

External

TTP

Reverse

Proxy

Authent

Server

Author.

Server

Identity

Server

App.

Server

User

Registry

HostApp.

Server

Credent.

Vault.

App.

Server

App.

ServerDomain

Bridge

(TTP)

CSIv2CSIv2

CSIv2

WS-S

WS-S Intern

et

InternetIntern

et

InternetPoint of

contact

Authentication provider Infrastructure converter

Customer alias

Customer alias

Federated Identity Management Across Domains

Token

Token

Token

Token

Token Token

Token

Token

WS-TrustServer

Token

Token

WS-Trust Server checking foreign Token

Web-based SSO Scenarios

• Redirect Mechanism

• Background communication

• Where are you from

• Privacy issues

GET:http://www.SP1.comGET:h

ttp://

www.IP.com

with IP

-Adre

sse of

SP1.com ls

para

mete

r

Service Provider 1 Identity Provider

User

302 www.ip.com

/original_request=

„GET:http://www.SP1.com“1.

2.

3.

Redirect of unauthenticated request to identity provider: Pull Szenario

Service Provider 1

Identity Provider

User

TOKENRedire

ct to S

ervice P

rovid

er

with to

ken as para

mete

r

Redirect:

http://www.IP.com/sp=....

4.

5.

Re-redirect back to Service Provider

TOKEN

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. web-services)

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

Service Provider 1

Identity Provider

User

TOKEN1

Redirect t

o Serv

ice Pro

vider

with to

ken as para

mete

r

GET:http://www.SP1.com

TOKEN1

GET:http

://www.IP

.com/

login

Form.h

tml

Dynamic Menue:

-Link to SP1

- Link to SP2

- Link to SP3

TOKEN1

TOKEN2

TOKEN3

„Clicked“ by user

Redirect of authenticated user to selected SP (Push Model)

Service Provider 1

Identity Provider

User

Back channel communication for extended user information

TOKENRedire

ct to S

ervice P

rovid

er

with to

ken as para

mete

r

Random number or extended user information (SAML)

Front channel

Redirect:

http://www.IP.com/sp=....

Pull mechanism

push mechanism

Front-Channel vs. Back-Channel

Service Provider 1

Identity Provider

User

Back channel communication for automatic provisioning

TOKEN: IP_Alia

s 123

Redirect t

o Serv

ice Pro

vider

with to

ken as para

mete

r

Allows mapping between IP Alias and own UserID for user

At IP: User_X, PW_X

At SP1: X_User, PW_Z

X_User, PW_Z, IP_Alias 123 User_X, PW_X, IP_Alias 123

Front channel mapping

Redirect:

http://www.IP.com/sp=....

Account linking with User Alias

WS-Profile Messages to

learn about requirements W

S-Federa

tion R

equests

based on W

S-Securit

y

Messages

Service Provider 1 Identity Provider, WS-Trust Server

Web Service Client

Application

WS-Profile data

1.

2.

3.

TOKEN

4.

5.

TOKEN

Secure Messages with „Active Profile“ – Web Service enabled communication

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 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 Assertion (example)

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

SAML embedded in SOAP Header

employee

TelCo Provider

SAML Assertion in Token

Link with Forms Post to TelCo

TOKEN

Mapping of all employees to ONE guest account for XYZ at access manager of TelCo

SSO

CompanyXYZ

Portal

login SPNEGO

Internal STI

Conference System

Own Token

Company: XYZ

User: foo

Email: foo@xyz.com

User: XYZ_guest

CN: foo

Email: foo@xyz.com

WS-Federation Active Profile Example

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

<saml:AuthenticationStatement AuthenticationInstant="2005-07-16T15:24:29Z"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> </saml:Subject></saml:AuthenticationStatement><saml:AttributeStatement> <saml:Subject>

<saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">emp1@xyz.com

</saml:NameIdentifier> </saml:Subject>

<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

When is this statement valid?

Who is the receiver?

Who is authenticated?

(subject)

What attributes does subject have?

ID and time of issued assertion, namespaces galore

<ds:Signature Id="uuid203f1582-0105-efbb-6039-8ce3efd72411„ xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><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>

Non-federation part of assertion – deals only with message security of assertion statement

How signature was created

Signature value to Check against

Who did it: Signers certificate so receiver (telco)

can check signature

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