View
1.064
Download
3
Category
Preview:
DESCRIPTION
Demonstrator presentation for a prototype in which a hybrid counterpart of claim-based and network-based authentication, is validated. The network-based instance is Shibboleth, while the claim-based one is MSEC's (KaHo Sint-Lieven) privacy-preserving IdM architecture. After the introduction of a few concepts, the raison d'être for this prototype is presented. Subsequently, the followed approach and and an evaluative conclusion are put forth.
Citation preview
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
Recommended