Identity Management Audun Jøsang University of Oslo NIS 2010 Summer School September 2010 http://persons.unik.no/josang/
Outline Identity and identity management concepts Identity management models User-centric identity management Management of SP identities Security usability Research challenges 2 2
Identity related concepts Entity A person, organisation, agent, system, etc. Identity A set of characteristics of an entity in a specific domain An entity may have multiple identities in the same domain Attributes Representation of a characteristic Transient or permanent, self defined or by authority, suitable for interpretation by humans and/or computers, etc Name is an attribute used as unique identifier Separation between identity and name is blurred in common language Digital identity Identity resulting from digital codification of attributes in a way that is suitable for processing by computer systems 3 3
Relationship between Entities, Identities and Attributes Entities correspond to Identities consist of Attributes systems persons names characteristics organisations 4 4
What is identity management? Representing and recognising entities as digital identities Managing name spaces Managing & issuing authentication credentials Covers AAA (Authentication, Access Control and Accounting) First identify, then authenticate, finally control access 5 5
Aspects of Identity Management technical cultural organisational psychological IdMan political social business & economical legal 6 6
Identity & access management Identity Representing and entities as digital identities Managing name spaces of unique names Mapping identities between domains Authentication Registration Credentials management Entity authentication Access Authorization Access control Accounting AAA: Authentication, Authorization & Accounting Identity Management Access Management 7 7
Authorization and Access Control Authorization Access rules specification Access Control John Mary HR Sales Policy definition by authority Policy encoding by custodian Policy enforcement by system 8 8
Basic Concepts Access control consists of: offline procedures, executed once online procedures, executed repeatedly Offline Online Registration Identification Who are you? Credentials issuance Authentication Is it really you? Authorization Access Control Are you authorized to access this resource? 10 10
Access control conceptual diagram WS-Security terminology and architecture (http://www.oasis-open.org/specs/index.php) System owner domain credentials 2 Subject registration 1 authorization 3 PAP IdP System owner policy 6 request PDP 5 4 decision request access request System resource access 7 PEP User authentication S + + object & access type S PAP: Policy Administration Point PEP: Policy Enforcement Point Offline PDP: Policy Decision Point IdP: Identity Provider Online 11 11
Who s identity? User s Ids and credentials Issued by: SPs & IdP Managed by users & SPs Application layer authentication Traditional identity management SP s Ids and credentials Issued by DNS registrars & CAs Managed by users & SPs Transport layer authentication Not traditionally part of identity management 12 12
Four types of identity management (1) Mgmt of user IDs and credentials on SP side (3) Mgmt of SP IDs and credentials on SP side (2) Mgmt of user IDs and credentials on user side (4) Mgmt of SP IDs and credentials on user side Only type 1 is traditionally considered part of IAM Types 2,3,4 are equally important for security 13 13
Zooko s Triangle of Id Properties Global No names land Unique Petnames Memorable No identifier can be at the same time global, unique and memorable 14 14
Application of Zooko s triangle Desirable properties of a name: Global: can be used in the whole world Unique: only one entity has this identifier in a domain Memorable: passing-bus test Names can only have 2 of these properties. Example: Pépés Pizza Global & Unique: Pointer e.g. URL: www.pepespizza.co.nz. Not easy to remember Global & Memorable: Nickname e.g. Pépés Pizza. There are proably multiple restaurants in the world called Pépés Pizza. Unique & Memorable: Petname e.g.: Pépés stored in my personal address book. 15 15
Passing bus test for memorability P é p é s P i z z a If you see a name written on a passing bus, and you can remember the name after 5 minutes, then the name is memorable 16 16
Name spaces of unique names Local name spaces Staff number Within company Social security number Within state/country Bank account number Within state/country Bank box number Within branch office Global name spaces Domain names IP addresses Telephone numbers Email addresses ISBN X.500 Directory URI and URL XRI DOI GUID 17 17
Identity Domains An identity domain is a network realm with a name space of unique names Management structures: Single authority, e.g. User Ids in company network Hierarchical: e.g. DNS (Domain Name System) A single policy is normally applied in a domain Integration/federation of domains Requires mapping of identities of same entity Requires alignment of policies Domain A Mapping Domain B 19 19
Silo domain model Legend: SP SP/IdP 1 SP/IdP 2 SP/IdP 3 IdP 1 2 3 Identity domain 1 2 3 # User name managed by IdP # # User credential managed by IdP # Service logon Service provision 20 20
Silo user-identity domains SP = IdP: defines name space and provides access credentials Unique name assigned to each entity Advantages Simple to deploy, low cost for SPs Disadvantages Identity overload for users, poor usability 21 21
Imagine you re a service provider Nice and simple 22 22
Imagine you re a customer It s a nightmare 23 23
Tragedy of the Commons fred 2008Oct9 TopSecret GuessMeNot 123abc Secret 123456 abc123 FacePass Password = Cow Brain = Green 24 24
Push towards Single Sign-On Users don t want more digital identities Low acceptance of new services that require separate user authentication Silo model requires users to provide same information to many service providers Silo model makes it difficult to offer bundled services, i.e. from different service providers Service providers want better quality user information 25 25
Kerberos simplified protocol Key Distribution Center Ticket Granting Server 4 5 6 Kerberos Database 3 Authentication Server Server Server Server Servers 2 1 6 6 Workstation 6 1 2 3 4 5 6 Request service Authentication Look-up user Request ticket Ticket Service access with ticket 27 27
Kerberos Advantages and limitations First practical SSO solution Centralized TTP (Trusted Third Party) model Uses only symmetric cryptography Requires Kerberos clients and servers + KDC Only suitable for organisations under common management (single domain) Does not scale to very large domains Not suitable for open environments (Internet) 28 28
Traditional Single Sign-On (SSO) Model Legend: SP SP 2 IdP SP 1 3 3 Centralised user-idp 3 3 3 # # Identity domain User name issued by IdP # Security assertion sent by IdP # # User credential managed by IdP # Examples: Kerberos, Service logon Service provision 29 29
Traditional SSO Single authority/infrastructure that acts as identity and credentials provider Single authority authenticates users on behalf of all SPs Advantages Well suited for SPs under single management, e.g. within large private and government organisations Good usability Disadvantages Politically difficult to implement in open environments. Who trusts authentication by other organisations? 30 30
Federated SSO model Legend : Federation Domain / Circle of Trust 1 2 3 SP IdP Identity domain # User name issued by IdP # SP/IdP 1 2 SP/IdP 2 3 SP/IdP 3 # User credential managed by IdP # Examples: Liberty Alliance, SAML2.0, WS-Federation, Shibboleth 3 3 SSO to other domains # Security assertion sent by IdP # Service logon Service provision Identity mapping 31 31
Federated SSO Identity Federation A set of agreements, standards and technologies that enable a group of SPs to recognise user identities and entitlements from other SPs Identity (and credential) provision as for the silo model Mapping between a user s different identities Authentication by one SP, communicated as security assertions to other SPs Provides SSO in open environments 32 32
Standards for Federated SSO What are the Standards? SAML (OASIS) Liberty ID-FF (Liberty Alliance), merged with SAML2.0 WS-Federation (IBM, Microsoft) Standards based solutions make life easier Multi-vendor interoperability Reduced technology lock-in Benefit from the experience of others 34 34
Profiles for Id Federation Front Channel Back Channel SP IdP SP IdP 3 3 3 3 Security assertion sent from IdP via client to service provider Security assertion sent directly from IdP to service provider 35 35
Open SSO identity model Legend : SP Distributed user-idp 2 SP 1 Distributed user-idp 3 IdP Common identity domain 2 2 2 3 3 3 # # User name managed by IdP # User credential managed by IdP # # Security assertion issued by IdP # Service logon Example: OpenID Service provision 36 36
Open SSO identity model Single common identifier name space E.g. based on URIs or XRis Distributed assignment of names Each IdP controls its own domain name Registers users under domain name Whoever controls a domain name can be IdP IdPs are involved for every service access Collect info about service access 37 37
OpenID self registration fred bad password 38 38
OpenID SSO Service Access 39 39
OpenID First Time Sevice Access 40 40
OpenID Characteristics Self registration ID Providers are not authorities You can be your own ID Provider and Server Only supports AAL-1 Not suitable for sensitive services Targets online services with AAL-1 Open to multiple forms of abuse Phishing 41 41
OpenID Phishing Legend : SP Distributed user-idp 2 SP 1 Attacker IdP Phishing attacker 2 Common identity domain 2 2 2 # User name managed by IdP # 2 # User credential managed by IdP # Phishing attack with OpenID # Security assertion issued by IdP # Service logon Service provision 42 42
OpenID Business Model For ID Providers Collection of market data Knows who uses which service Fragmentation of ID Provider market is a threat For Service Providers (Relying Party) Potentially more traffic and business For users Avoid multiple identities Avoids typing passwords (Must still type OpenID name) 43 43
Microsoft s InfoCard model Legend : SP IdP SP 1 SP 2 InfoCard user-idp 3 # Identity domain User name managed by IdP # 3 3 3 3 SSO to other domains # # User credential managed by IdP # Security assertion issued by IdP # Service logon Card Selector Service provision 44 44
Global user identity domain. IdP 4 Legend : Common Identity domain IdP SP 1 SP 2 SP 3 User entity User name (X.509 Cert.) issued/registered by IdP # 4 4 4 4 4 4 Authentication credential Issued by IdP # Service provider entity Example: PKI with user certificates Service access Service provision 46 46
Global user identity domain IdPs define/register names and issue/record credentials All SPs recognise and authenticate the same user by the same name Advantages Simple to manage for users and for SPs Disadvantages Politically difficult to define name space SPs don t trust names/credentials issued by third party Utopic solution 47 47
A closer look at SSO Single manual authentication Repeated automated authentications SSO is simply automated authentication Where to put the automation? On server, network and client side: Traditional SSO Kerberos, InfoCard On server and network side: Federated SSO On client side only: Local user-centric SSO 48 48
SSO technology location Client side Network Server side Kerberos: Federated models: Information card: Local user-centric: 49 49
User-centric identity manageent Buzzword with positive connotation Possible interpretations: 1. Any architecture that improves the user experience 2. Giving users control of their identities 3. Giving users control of privacy 4. Identity management technology located on the user/client side: Local user-centric identity management 50 50
Client-side location for local user-centric identity management Workstation e.g. SW based password wallet Mobile phone e.g SW/SIM based password wallet offpad e.g. display smartcard, ipod or other offline device 52 52
Local user-centric model Legend: SP SP/IdP 1 SP/IdP 2 SP/IdP 3 IdP 1 1 2 2 3 3 # Identity domain User name managed by IdP # PAD Repository of authentication tokens and Ids. # User credential managed by IdP # Service logon Service provision Personal Authentication Device 53 53
Local user-centric: Imagine you re a customer It s a dream 54 54
Advantages Improved usability Local user-centric SSO Compatible with silo identity domains Low trust requirements Strong privacy protection Disadvantages Does not allows SPs to control service bundling Does not allow SPs to collect user information Requires user-side software or hardware Requires user education 55 55
SSO model suitability Federated SSO, well suited for Large organisations Government organisations Closely associated organisations Related Web service providers Local user-centric SSO, well suited for Open networks e-commerce Unrelated Web services 56 56
Combining federated and user centric identity management Federation domain 1 Federation domain 2 Federation domain 3 Personal Id domain 58 58
Federation technology resources Shibboleth Open source software http://shibboleth.internet2.edu/ Liberty Alliance Industry consortium Provides specifications and white papers http://www.projectliberty.org/ SAML 2.0 OASIS XML format standards for exchanging authentication info http://www.oasis-open.org/ WS-Federation IBM, Microsoft et al. Specification based on the WS-Security roadmap (OASIS standards) http://www-128.ibm.com/developerworks/library/specification/ws-fedworld/ 59 59
Id Federation Standards Evolution 2002 2003 2004 2005 2006 2007 2008 2009 2010 Liberty phase 1 Liberty 1.1 & 1.2 Liberty Federation SAML 1.0 SAML 1.1 SAML 2.0 Shibboleth 2000 Shibboleth 1.2 Shibboleth 2.0 Microsoft Passport 1999 Microsoft Passport Microsoft Live Id Card Space Information Card 2009 OpenID 1.0 OpenID 2.0 WS Federation MS / IBM WS Federation 60 60
Service Provider Identity Authentication? Cert TLS SP authentication User Client Internet Service Provider Server Authentication of business and government websites Mostly ignored in identity management discussions PKI is not enough Extremely important!!! 61 61
SP identity management Traditionally not considered as part of identity management No clear unique SP name Currently a major problem Phishing attacks Virus, Trojan attacks GUI attacks Security fails despite strong crypto. Poor usability Poor platform security Identity federation and SSO no solution to SP identity management problems. 62 62
SP identity management Common domain model Domain Name Registrar / IdP 4 CA 5 Legend: SP Identity domain # Domain name issued by IdP # User 1 User 2 User 3 SP entity 4 4 4 Domain name registrar / IdP 5 5 5 Certificate Authority # X.509 Certificate issued by CA # Service access Example: Browser PKI SP authentication 63 63
Common SP identity domain Global name space for SP names: URIs Multiple authorities acting as IdP and credentials provider All users/clients authenticate the same SP by the same name and credential Advantages Simple model (PKI in practice), technology exists Good usability possible when well implemented Disadvantages Hard to implement well 64 64
Meaningless authentication with TLS View padlock 4 Display padlock Login Page Victim Client 1 Spam phishing email Service request to fake bank2 3 5 TLS setup TLS Cert A 4 Connection Fake login page Hijacked login 6 A Attacker Server ---- Fake Bank ---- 65 65
The great server certificate swindle SSL designed to provide: Confidentiality, possible with RSA or Diffie-Hellman Authentication, possible with RSA only RSA requires certifcitates, Diffie-Hellman not In practice, SSL does not provide authentication Only confidentiality RSA not needed Conclusion: Certificates worthless for SSL Only valuable for marketing to stimulate (false) trust 66 66
A phishing example Hawaii Federal Credit Union Genuine bank login https://hcd.usersonlnet.com/asp/use RS/Common/Login/NettLogin.asp Fake bank login https://hawaiiusafcuhb.com/cgibin/mcw00.cgi?mcwstart 67 67
Certificate comparison 1 Genuine certificate Fake certificate 68 68
Certificate comparison 2 Genuine certificate Fake certificate 69 69
Certificate comparison 3 Genuine certificate Fake certificate 70 70
Petnames in server authentication Domain Name Registrar / IdP 4 CA 5 4 1 4 2 4 3 Legend : # # Identity domain Domain name issued by IdP # Petname defined by user # PDA / mobile User / IdP 1 User / IdP 2 User / IdP 3 4 4 4 5 5 5 # SP entity Domain name registrar / IdP CA X.509 Certificate issued by CA # Service access SP authentication Identifier mapping 71 71
Local user-centric SP identity domains Users create petname for each SP Petnames can be names, graphics or sound Petnames are mapped to global unique names Advantages Improved usability Disadvantages Requires additional technology for managing SP identities, e.g Mozilla TrustBar 72 72
Local user-centric server authentication 2 User HTML B Client 5 3 Cert B 1 6 Access SSL setup Login page Login Cert B 4 2 HTML B B Server Bank 2 SSL 73 73
SP identity management Principle of Mozilla TrustBar Personalised graphical logo and/or sound as site identifier Toolbar for the Mozilla and Firefox browsers Server certificates personalised by user Personal graphics or sound played when SP certificate recognised by browser 74 74
Identity management security problems Poor security usability creates vulnerabilities Password fatigue leads to password re-use SSO aimed at improving usability, but System complexity Privacy threats Requires trust between many parties Malware that attacks platforms 75 75
IdMan with Man-in-the-Browser Trojan Attacks become more sophisticated Man-in-the-browser Trojan is malware that changes transaction data while being submitted from browser to bank. e.g. Zeus Trojan User authentication is insufficient Data/transaction authentication is necessary Requires dual channel authentication, assuming that the 2 nd channel is not compromised. 76 76
Man-in-the-browser attack Bank Server 2 4 1 3 User Client 1. Specify sender/destination accounts and amount 2. Change destination account and amount 3. Transmit wrong transaction data 4. Send money to attacker 77 77
5 Protecting Against Man-in-the-browser Attack 4 Mobile phone 3 Cellular Bank Server 8 1 6 Internet 2 7 User Client 1. Specify sender/destination accounts and amount 2. Data transmission 3. SMS with authorization code, destination account and amount 4. View SMS 5. Decide if transaction data in SMS are correct 6. Copy authorization code to browser 7. Data transmission 8. Verify authorization code and execute transaction 78 78
Research challenges Usability of security Seamless integration of user-centric and other models Protocols Mobile integration Dual channel authentication protocols Trusted platforms Privacy Recovery from Id theft Proving that false Id profile is not you Personalisation of SP identities Name spaces Governance 79 79
Thank you for your attention Questions? 80 80