Shibboleth-based hybrid authentication

MobCom Workshop

February 6th, 2013

Faysal Boukayoua - MSEC

Overview

• Intro

• Motivation

• Prototype

– Approach

– Interactions

– Evaluation

– Demo

2

Intro Context

3

MobCom

Loyalty cards & discount vouchers

Context-aware services

Flexible Access Control

Shibboleth-based hybrid

authentication

Intro The old days

4

University A

Library B

University C

Student Admin

Web Mail

e-Learning

Literature DB

e-Learning

Research DB

e-Journals

Authorization User Administration Authentication

Resource Credentials

Source: SWITCHaai (http://goc.pragma-grid.net/pragma-doc/pragma-summit/aai_introduction.ppt)

Intro Now

5

University A

Library B

University C

AAI

Student Admin

Web Mail

e-Learning

Literature DB

e-Learning

Research DB

e-Journals

Authorization User Administration Authentication

Resource Credentials

Source: SWITCHaai (http://goc.pragma-grid.net/pragma-doc/pragma-summit/aai_introduction.ppt)

Intro What is Shibboleth?

• Federated identity management middleware

• Interorganisational:

– identities

– trust

• SAML 2.0-compliant

• Widely in use

6

Intro Shibboleth authentication

7

User User’s browser Identity provider Service provider

1. Request resource

3. Prompt for authentication

4. Authenticate

2. Redirect to IdP

5. Assert attributes and redirect

6. Return resource

Intro MSEC’s IdM architecture

8

SPi

3. Review query

4. Confirm

IdPX

IdPY

IdPZ

User

5. Release_attrs

1. Mutual auth.

2. Attribute_query

• Smartcard technology • Support for: Mutable and new attributes Pseudonimity and anonymity Multiple identity providers Separation between IdPs and SPs

Motivation

9

Shibboleth MSEC’s arch.

Must modify workstation?

Default: no Yes

Standards & interoperability

Strong authentication Default: passwords Yes

User consent Default: no Yes

Selective disclosure Default: no Yes

Trust in IdP

SP-IdP collusion Yes No

Motivation (2)

10

Shibboleth MSEC’s arch.

Must modify workstation?

Default: no Yes

Standards & interoperability

Strong authentication Default: passwords Yes

User consent Default: no Yes

Selective disclosure Default: no Yes

Trust in IdP

SP-IdP collusion Yes No

Can we: • maintain strengths? • mitigate drawbacks?

Prototype Approach

11

4. Review query

5. Confirm

Shibboleth Identity Provider

IdPX

IdPY

IdPZ

User

2. Mutual auth.

6. Release_attrs

Shibboleth Service Provider

1. SAML attribute query

7. SAML attribute assertion

3. Attribute_query

6. Review and consent

Prototype Interactions

12

Phone + secure µSD User Service Provider

User’s browser

1. Request resource

4. Scan QR challenge

3. Show QR challenge

8. Authenticate

10. Assert attributes and redirect

11. Return resource

5. Show feedback

Identity provider

9. Disclose requested attributes

2. Redirect

Prototype Evaluation

• User consent

• Selective disclosure

• Resilience against phishing

• Shibboleth SP unmodified

• Portable across workstations

• Less trust in Shibboleth IdP

13

Prototype Demo

14