Claim-based versus network-based identity management: a hybrid approach
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Claim-based versus network-based identity management: a hybrid approach

  • 1,193 views
Uploaded on

This paper proposes a hybrid approach that combines claim-based and network-based identity management. Partly by virtue of the principle of separation of concerns, better security and privacy......

This paper proposes a hybrid approach that combines claim-based and network-based identity management. Partly by virtue of the principle of separation of concerns, better security and privacy properties are attained. Overall trust is diminished, while simultaneously reducing multiple actors' exposure and value as a target of attack. The proposed architecture also facilitates interoperability and pluralism of credential technologies, authentication protocols and operators. In addition, the user has more control over his personal data than with current network-based identity management systems. A prototype demonstrates the feasibility of the proposed approach.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,193
On Slideshare
1,192
From Embeds
1
Number of Embeds
1

Actions

Shares
Downloads
13
Comments
0
Likes
0

Embeds 1

http://www.linkedin.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Claim-based versus network-basedidentity management: a hybridapproachFaysal BoukayouaMSEC research groupKaHo Sint-Lieven, GhentMOBISEC, Frankfurt am MainJune 25-26, 2012
  • 2. 2Overview• Introduction• Motivation• Architecture• Prototype• Evaluation• Future work
  • 3. 3Introduction: identity management Admini- stration Goals: Authenti- Management • Identity assurance cation & & • Enable business & assertion maintenance security applications Communi- Policy cation &enforcement discovery Correlation & binding Loosely based on the ITU Y.2720 standard
  • 4. 4 Based on The Identity Crisis: Security, Privacy and Usability Issues in Identity Management (Alpár et al)Introduction: network-based identitymanagement 3. Return token 2. Authenticate at IdP 1. Request service
  • 5. 5Introduction: network-based identitymanagementExamples• Password-based Shibboleth• Password-based OpenID• Google ClientLogin
  • 6. 6 Based on The Identity Crisis: Security, Privacy and Usability Issues in Identity Management (Alpár et al)Introduction: claim-based identitymanagement 1. Request service 2. Send policy 3. Supply claims
  • 7. 7Introduction: claim-based identitymanagementExamples• eID technology• Anonymous credential systems• Standalone X509 certificates
  • 8. 8Introduction: hybrid examples• SAML authentication context classes: ▫ Smartcard PKI ▫ MobileTwofactorContract ▫…• Shibboleth and OpenID with alternative authentication• eID authentication portals
  • 9. 9Motivation: network-based IdM  Standardised protocols  Widely deployed 3. Return token 2. Authenticate at IdP 1. Request service
  • 10. 10Motivation: network-based IdM  Little change to user’s workstation 3. Return token 2. Authenticate at IdP 1. Request service
  • 11. 11Motivation: network-based IdM  Phishing attacks  Passwords: low security 3. Return token 2. Authenticate at IdP 1. Request service
  • 12. 12Motivation: network-based IdM Identity provider:  Single point of failure 3. Return token  Centralised storage  High-value attack target 2. Authenticate at IdP  Trust: monitoring, linking, profiling 1. Request service
  • 13. 13Motivation: claim-based IdM User-centric  Consent  Information flow 1. Request service 2. Send policy 3. Supply claims
  • 14. 14Motivation: claim-based IdM ∃ privacy-preserving credentials  Selective disclosure   monitoring, linking, profiling  New ones in development 1. Request service 2. Send policy 3. Supply claims
  • 15. 15Motivation: claim-based IdM eID infrastructure country-wide  Large user-base  Only country-wide  standardisation & interoperability… 1. Request service 2. Send policy 3. Supply claims
  • 16. 16Motivation: other considerations• Service provider ▫ Reliable user info ▫ Broaden user base ▫ Externalise IdM cost• User ▫ Easily switch to other claim-based technologies ▫ Use credentials across services
  • 17. 17 Architectural overview : added : discarded ServiceProvider 1 User’s workstation Claim Provider 1 Identity Broker Identity Provider User Agent Claim Provider 2
  • 18. 18Architecture: service provider • Unmodified at protocol level • Minor configuration required ▫ Prerequisite exchange (=required user attributes) ▫ @ trust establishment logic
  • 19. 19Architecture: claim provider • Claim issuance • Storage of partial identities • Multiple providers • ∃ privacy-preserving credentials
  • 20. 20Architecture: user agent • Present claims to identity broker • Claims management • User feedback & consent • Automated policies • Phishing protection • Various support functions • ...
  • 21. 21Architecture: identity broker • Support claim technologies • Authentication & assertion to service provider • No attribute storage ▫ No storage-related user dependence  generic functionality • Privacy-preserving claim technologies ▫  monitoring, linking, profiling
  • 22. 22 Architecture: message flow User User’s Identity ServiceClaim Providers Agent workstation broker Provider a. Request credentials b. Authentication c. Issue credentials 1. Request service 2. Redirect 4. Authentication 4. Assert attributes & redirect
  • 23. 23 Prototype ServiceProvider 1 User’s workstation Claim Provider 1 Identity Broker User Agent Claim Provider 2
  • 24. 24Prototype: user agent • Samsung Galaxy S • Android 2.3.4 • Tamperproof storage: Giesecke & Devrient Mobile Security Card • 2 setups: ▫ Service accessed on smartphone ▫ Out-of-band authentication
  • 25. 25Prototype: identity broker• Claim technologies: ▫ Idemix ▫ Proof-of-concept IdM architecture• Authentication & attribute assertion protocol: ▫ Shibboleth ▫ Service provider prerequisites in SAML metadata ▫ (others in progress)
  • 26. 26 Evaluation IdP: identity provider IdB: identity broker SP: service provider Compared to network- Compared to claim- based IdM based IdM • Feedback on user agent Feedback on user agentPhishing • IdB configured in user agentIdP • Multiple IdBs (generic task) n/a (many issuers)• Single point of failure • User can select IdB• High-value attack • IdB stores no data target • SP protocol unchanged • Credential use across • Harness claim-based services credentialsInteroperability • SP: broader user base at little cost • User: more services with same credentials
  • 27. 27 Evaluation IdP: identity provider IdB: identity broker SP: service provider Compared to network-based Compared to claim- IdM based IdMUser consent User consent on user agent for each transaction • Multiple IdBsTransaction • Leveraging: Additional user trust neededmonitoring, linking, • Selective disclosure in IdBprofiling • Pseudonymity • Anonymity
  • 28. 28Future work: prototype• Out-of-band session transfer ▫ Bluetooth ▫ NFC ▫…• Trust enforcement ▫ Middleware ▫ Browser hardening• Other claim technologies• Other authentication & assertion protocols
  • 29. 29Future work: new concepts• Tamperproof module in identity broker ▫ For less privacy-friendly technologies ▫ Enforce selective disclosure• Identity broker entirely on smartphone ▫ Trust enforcement is paramount! ▫ Research mobile tamperproof modules• Trust establishment strategies ▫ Without breaking standards?
  • 30. 30Questions?