Why Identity Management. Identity Management. What We Cover. Role of Digital Identity. Digital Identity. Digital Identity (or network identity)

Transcription

1 Why Identity Management Identity Management Claudiu Duma Identity crisis Privacy concerns Identity theft Terrorist threat Department of Computer and Information Science What We Cover Digital Identity (or network identity) Digital identity Problems with digital identity Requirements Identity management systems Collection of information relating to an individual, created and managed as a single unit, stored in electronic format in a given identity system. AKA user account, record, profile Digital Identity Role of Digital Identity May contain: Real attributes of an individual Personally identifiable information (PII) May or may not be traceable to an individual (person) Prerequisite for: Authorization and access control Logging and accountability Reputation 1

2 Multiple Identities Multiple Identity Systems Digital Identity on the Internet: Current Problems 1. Inconvenience 2. Inconsistence 3. In-transience 4. Insecurity 5. Privacy Problems: Inconvenience Problems: Inconsistency People have to Register and create multiple accounts Create strong, independent passwords Remember or securely store all this info Change passwords regularly Human or machine Many sites require CAPTCHAs Various types of registration/login systems around Many, many different authentication schemes Functionality greatly varies across these systems Problems: In-transience Online identity is not transitive An account in domain A is useless at domain B So is reputation, credibility, credit, experience across domains Problems: Insecurity Current infrastructure is basically insecure People lose/leak passwords People choose weak passwords Users machines can be compromised Trojans, Keyloggers, etc. Servers could be compromised too E.g. Lexis-Nexis massive leak Find and attack the weakest link! 2

3 Problem: Privacy Identity Management (IdM) Sites collect a lot of personal data Users can not control their disclosed data Vast propagation of sensitive information Very prone to leaking. Leaks are also vulnerable to weakest link. Provides the tools for managing identities In a consistent, automated, interoperable, secure, and privacy preserving way Main functionalities Single sign-on (SSO) Attribute sharing Stakeholders and Their Main Requirements Identity Management Components Users Convenience Control the disclosure and propagation of their data Service Providers User authentication Access control to resources Governments Reliable I&A of individuals Reliable signature User Identity Manager Services Architectural Choices User-centric IdM Centralized IdM Federated IdM National digital identity infrastructures Centralized IdM Systems 3

4 Centralized IdM: Microsoft Pasport Goal a one-stop-shop where personal information is stored and used for online activity Provides Single sign-on Wallet: credit card info, contact info, etc. Microsoft Passport Architecture Wallet functionality is similar 1. Request page at SP 2. Redirect to Passport Server 3. Checks Ticket Granting Cookie (TGC) 4. If not existent, MPS authenticates user 5. MPS sets TGC (encrypted with K MPS ) 6. MPS redirects to SP, with token (encrypted with K MPS-SP ) in header 7. MPS sets an encrypted cookie Service Provider (SP) Microsoft Passport Server (MPS) Cookies as Authenticators Problem No proof of cookie ownership Cookies can be stolen and reused E.g. Cross Site Scripting (XSS) In Kerberos, proof of token ownership is required Remedy? token proof Concerns with the Passport Vulnerable to several attacks Cross site scripting Bogus merchant Man-in-the-middle DNS attack Reshaped into Windows Live ID! Security concerns User interface Key management Central point of attack Persistent cookies Automatic credential assignment Privacy concerns All under control of Microsoft Federated IdM Systems Federated IdM: Liberty Alliance Goal Link user identities at different systems Dominant industry effort An open standard for Federated IdM Aims at providing and supporting interoperability Different implementations exists Provides SSO Cross domain data (attribute) sharing Anonymous data sharing 4

5 2. IDP sets a cookie Liberty Alliance Architecture Liberty Liberty Identity Identity Federation Framework (ID-FF) (ID-FF) Identity federation Account linkage SSO Liberty Liberty Identity Identity Service Service Interface Specifications (ID-SS) (ID-SS) Enables interoperable identity services such as alert, calendar, wallet, contacts, geo-location, etc. Liberty Liberty Identity Identity Web Web Service Service Framework (ID-WSF) Framework for interoperable identity services, permission based identity sharing, identity service description and discovery, etc. Liberty Liberty specifications build build on on existing existing standards XML, XML, SAML, SAML, SOAP SOAP Circle of Trust Model Principal G F F A Network identity providers E E D Circle of trust Business agreements Service level agreements (SLA) Policies, guidelines, acceptable use policies (AUP) Identity provider (IDP) (e.g. a bank) Authentication infrastructure Maintains core identity attributes B C Service providers (SPs) Offer services Don t need to invest in authentication infrastructure Identity Federation Identity Federation Identity linking alice@sp1 Alice_S@idp alice@sp1 Alice12@sp2 IDP IDP Alice12@sp2 aiw@sp3 Alice federates some of her identities, but not all of them aiw@sp3 Federated Identity Life-Cycle Federate an Identity: Introduction Metadata Metadata exchange exchange Federation Federation Single Single sign-on sign-on (already (already federated) federated) Name Name registration registration Airline. Inc (IDP) Welcome Alice You Airline. may federate Inc (IDP) your Airline.inc identity with any Member other of identities AAG you may Login: have with Alice members of our affinity group Alice AAG Pass: ***** Do you consent? ***** Yes Yes CarRental.inc (SP) Single Single logout logout Federation Federation termination termination Opt-in policy! 1. Logins to IDP Airline.Inc (IDP) 5

6 Federate an Identity: Account Linking CarRental.Inc Welcome Alice123 We CarRental.Inc noticed you recently sign-on to Airline.inc Member of AAG Would you like to federate Login: your CarRental.inc Alice123 Alice123 and Pass: Airline.inc ***** identities? ***** Yes Yes 5. Asks for federation 4. Checks cookie 3. Logins to SP CarRental.inc (SP) Common Domain Cookies Airline.Inc (IDP) Circle of trust common domain XXX.AGG.inc Airline.AGG.inc Common domain service sets cookie CarRental.AGG.inc Common domain service reads cookie CarRental.inc (SP) Airline.inc (IDP) Account Linking Multiple IdP and Multiple IDs IDP account Federate account Alias: mr3ttj Domain:.com Name: dtvlir Alias: xyrvds Domain:.com Name: pfk9uz account Federate account Alias: dtvlir Domain: IDP.com Name: mr3ttj work profile IDP1 IDP1 account home profile User handlers no global ID prevents collusion between SPs Federate account Alias: pfk9uz Domain: IDP.com Name: xyrvds Needs mechanisms to discern among IDPs and SPs IDP2 IDP2 SP4 SP4 Generic SSO Example: SSO with Browser Artifact 6. User gets service from SP 1. User accesses SP CarRental.inc (SP) 5. Authentication assertion checked 4.1. Back channel 4. Auth assertion or handle to assertion 2. AuthRequest() 3. Authentication assertion issued 0. Logins to IDP Airline.inc (IDP) 6

7 Assertions Signed claims Use Security Assertion Meta Language (SAML) SAML assertions Authentication assertion Authorization decision assertion Attribute assertion XML-based SAML Assertion Example <saml:assertion AssertionID="SqMC8Hs2vJ7Z+t4UiLSmhKOSUO0U > <saml:conditions NotBefore=" T21:42:12Z" NotOnOrAfter=" T21:42: 43Z"> </saml:conditions> <saml:authenticationstatement AuthenticationMethod= "urn:oasis:names: :password"> <saml:subject xsi:type="lib:subjecttype"> <saml:nameidentifier Format="urn:liberty:..:federated"> C9FfGouQdBJ7bpkismYgd8ygeVb3PlWK </saml:nameidentifier> <lib:idpprovidednameidentifier> C9FfGouQdBJ7bpkismYgd8ygeVb3PlWK </lib:idpprovidednameidentifier> </saml:subject> </saml:authenticationstatement> <ds:signature> <ds:digestvalue> ZbscbqHTX9H8bBftRIWlG4Epv1A= </ds:digestvalue> <ds:signaturevalue> H+q3nC3jUalj1uKUVkcC4iTFClxeZQIFF0nv HqPS5oZhtkBaDb </ds:signaturevalue> </ds:signature> </saml:assertion> Permission-Based Attribute Sharing Permission-Based Attribute Sharing 1. Access site and buy 2. Shipping address? 3. Use my profile SP 4. Where is AP? 5. Use this AP 6. Give me address 10. Here is the address IDP Liberty specifies only technical guidelines No common interface for setting policies Liberty specification enables Principal s privacy but do not ensure it. 7. Check permission 8. Give permission 9. Could store permission Identity service could be the user! Attribute Provider (AP) Concerns with Liberty Alliance Concerns with Liberty Alliance User incur security & privacy problems Security One secret gives access to everything IdP can impersonate users across the circle of trust IdP can falsely deny access to users across the circle of trust Privacy IdP has real-time surveillance capabilities IdP and SPs may share user information Opt-in policy not very popular SPs lose their information autonomy IdP is one point of failure IdP has real-time surveillance capabilities Competitive intelligence of which users are services at what time All data sharing must go through IdP Liberty doesn't specify how authentication relations are maintained Maybe susceptible to same attacks as Passport 7

8 Other Federated IdM Systems WS-Federation An identity metasystem Set of protocols for distributing claims Based on SAML IBM, Microsoft, etc. working with OASIS Open standard User-centric IdM Systems User-centric (or local) IdM User-centric IdM Goals: No trusted third party Support multiple identities Avoid the interchange of user data between other parties Really keeps the user in control! Base idea: user is its own IdM Alice s profiles Identity Manager 1 2 HTML / HTTP 3 4 SOAP / HTTP SP Identity Agent Info about users Limitation of User-centered IdM Information is stored in two places Unsigned claims Not-portable Security of the client! End-user computer could be compromised Possible solution: Trusted Computing Platform National Digital Identity Infrastructure 8

9 National IdM Infrastructure Security Requirements e-government The interaction between state authorities and society with help of information and communication technology Goals: Improves services for citizens (e-voting, e-taxes, etc) Reduce retention periods and costs Major requirements: Security and privacy (paramount) Scalability Flexibility Entity authentication Data origin authentication Confidentiality Non-repudiation Electronic Signature Requirements for qualified signature (EU directive) Created by a secure signature-creation device (SSCD) In contact with the signature-creation data (Private key) Based on qualified certificate Contains the signature verification data (Public key) Certification service providers (CSP) Public or private organizations that asses SSCDs and CSPs Case Study: Austrian Citizen Card Signature-Creation System PIN should not be intercepted Data to be signed (DTBS) should not contain dynamic or hidden information Display should be trustworthy What you see is what you sign! Identification: Austrian Citizen Card Prohibit Inference: Sector Tags Goal: Unequivocally establish the individual Avoid digital twins! X509 certificates use distinguished names / O=LiU / OU=IDA / CN=Claudiu Duma / Qualified certificates use persona binding Name + CRR Number + date of birth CRR = Central Register of Residents 9

10 Application Environment Concerns and Challenges Concerns Integrity of the capsule and the trusted-paths Revocation of compromised certificates Tamper-resistance Further challenges Cross border IdM (Pan-European digital ID) Open the infrastructure to private sector (typical service providers) 10