OpenID and identity management in consumer services on the Internet

OpenID and identity management in consumer services on the Internet Kari Helenius Helsinki University of Technology kheleniu@cc.hut.fi Abstract With new services emerging on the Internet daily, users need to manage and remember more and more username/password pairs which are needed to authenticate to those services. The Single Sign-On (SSO) concept is taking the step from enterprise world towards free Internet to ease the authentication and identity management of the users. One strong candidate for this purpose seems to be OpenID. This paper discusses OpenID standard and how enterprise style SSO concept can be copied to open Internet where several identity providers are working and managing their own users and identities. It also discusses about extendability and suitability of OpenID, issues it may raise and if it can meet the future requirements and is it sufficient in general to act as a SSO protocol for Internet. KEYWORDS: OpenID, SSO, Identity management 1 Introduction In a past few years the Internet has taken a big leap from static web pages to dynamic and rich web applications where users can create, manage and share their own content and consume, discuss and share further the content created by other users. Services like YouTube, MySpace and Facebook are more or less familiar to everyone, and of course there is Google which is releasing new services out all the time. This huge number of services has created a problem, namely active Internet users are forced to remember many username/password pairs for these different services. In order to improve user experience these service providers have come together to specify methods to allow users to share their identity among different services in secure manner without the risk of revealing the actual password or any confidental information to other services. In enterpise environments, these issues have been solved by SSO system usually provided by a commercial vendor, and by integrating all services inside enterprise to use this system. On the Internet an open source standard called OpenID has adopted main features of SSO and it is getting more and more popular with big service providers standing behind it. Can the SSO paradigm really be used in the Internet environment where no centralized identity management exists? How well will the simplified OpenID protocol work in such environment and can it meet future challenges? Identity federation, a concept implemented by SSO, means sharing user identity, data and other user specific attributes across multiple services. In order to avoid leaking private data to non-authorized parties, a trust relationship between applications or between user and application is required. In this paper we take a look how these attributes are shared and how this relationship is created to ensure that private data is passed only to authorized parties. 2 Identity management In modern Internet an identity is required to perform various tasks. Whether it is writing a comment to a blog or paying bills using bank, customer needs to somehow identify himself for the service. Identity in its simplest form means some sort of unique identifier which can be used to distinguish a person. Relationship between person and identities is either one-to-one or one-to-many meaning that identity points always to one person, but it is possible that this person has several identities. In order to identify someone, his claimed identity must be authenticated by some party. Easiest method of authentication is to perform it against the party who is claiming the identity. That however would not be very trustworthy because everyone can claim that their identity is whatever they want and also agree that being true. A real world example is that everyone could print their own passports. So, in order to authenticate claimed identities a trusted party is required.[5] Different kind of identification methods are available and they vary depending how strong security is required. Identification is needed to guarantee that the user really owns the claimed identity. For example passport contains a photo of the owner so even if someone manages to steal that document he probably can not use it. With computers the most typical identification is some sort of shared secret - password. By entering his secret, user proves to service that he is who he claims to be. Password is a compromise between security and usability. It is not considered strong because it can stolen, guessed or broken too easily, but from user point of view it is easy to use and thus suitable for most of the services. Because not being strong enough, simple passwords are not used in critical services like in banks. Usually those use passwords combined with some other method like for example one time password list. Pieces of extra information that is related to identity are called attributes. If passport is used to verify an identity of a person, his name and date of birth obtained from that identity are considered as attributes. Just like with identity, these attributes must be authenticated aswell in order to be consider as trusted. If identity is authenticated by trusted party, like with passport that is issued by government authoritires, the related attributes are usually as well. However,

it is also possible that authenticated identity can contain nonauthenticated attributes - this is especially case with OpenID, as we introduce later in this paper. 3 Single Sign-On (SSO) Amount of web applications is growing rapidly. New services are released on the Internet all the time and more and more applications inside corporations are used with regular web browser instead of being separate desktop applications. Running the applications centrally at the server reduces administrative and maintenance costs dramatically, because only one instance of application needs to maintained. Usually each of these applications require users to authenticate into them separately forcing people to remember separate credentials to each application. Each application also contains separate user database and account management logic. In a corporate network there can be easily tens of different applications containing redundant information about user accounts and their permissions. In order to reduce costs that are required to maintain the user information and also to ease the usage of these applications, the SSO concept was brought to enterprise environments. This concept has been around for couple of decades - at first implemented using proprietary solutions [10], but during the last few years Security Assesrtion Markup Language (SAML) maintained by OASIS has become the standard protocol [5]. SAML is a XML based framework designed to pass identity information between different parties in a secure manner. It has been designed as a flexible and extendable framework based on XML messages. It is not tied to any specific protocol or environment. Using SAML in web environment where some of the messages are passed between parties using browser as a intermediary is just one use-case for it. SSO stands for Single Sign-On and in its simplest form means a way where user can access several applications using centrally managed account information and performing authentication only once. Typical SSO environment consists of services that users are accessing, called service providers (SP), and identity provider (IdP). When SP needs to authenticate user, it delegates this task to IdP that performs the actual auhentication of the user - usually using username/password pair but stronger authentication like some biometric solution is of course possible. After IdP has authenticated user, it provides this information back to SP which can then proceed and offer the services to the user. Along with user identifier, IdP can also provide or SP can query different attributes for the specific identity. Typically these attributes are information about the user (full name, email, phone number) or information about different roles (normal user, administrator). Based on these attributes SP can perform the actual authorization process and restrict or allow the access to certain features and information in the service. In enterprise environment links between SPs and IdP are usually static. IdP that SP should use to authenticate users is preconfigured in it. This kind of relationship is called circle of trust (CoT). Mutual authentication is used inside CoT between parties to assure that only trusted SPs are authenticating users through IdP and that only trusted IdP provides information about the user. Because of CoT, all the information provided by IdP can be considered trusted. Because CoT allows IdP to recognize which SP is requesting attributes, it is possible to limit privacy of certain attributes. Enterprise might want to integrate some 3rd party SP as a part of their CoT allowing users to access this SP using their existing user accounts. In such case company might limit the accessible attributes for that service to only necessary ones. Even though user accounts are stored in IdP, it is very often necessary to store some of the user attributes locally in SP. Usually this kind of values are needed in internal queries in SP and requesting them every time from IdP would cause severe decrease in performance. Attribute propagation is used to synchronize the parameters between IdP and SP. When attributes are modfied in IdP, a special message with new values is sent to SP so it can update its existing values with new ones. Single Log-Out (SLO) is used in SSO environment to log out user from all SPs when he logs out from IdP [5]. In web environment this is performed by redirecting user sequentially to all necessary SPs and passing SAML logout message with it. Usage of SLO guarantees that when user wants to log out, he is also logged out from all SPs leaving no unwanted sessions open between SP and browser. 4 Identity Management with OpenID OpenId was originally developed by Brad Fitzpatrick in 2005 to avoid comment spamming to LiveJournal online articles. Original idea was that when someone wanted to leave a comment, he would enter URL to his blog supporting OpenID and LiveJournal would perform a verification procedure to make sure that person writing the comment is also owner of the given blog[5]. The higher architecture in OpenID is similar to SSO, but used terminology is a bit different. The actual service that user wants to use is called relaying party (RP) instead of SP. It relies to information offered by identity provider. Party that provides the actual authentication of identity is called OpenID provider (OP) instead of IdP. Unlike SAML, OpenID has been designed with lightness and easy implementation in mind. Whereas SAML consist of several different specifications and extensions, OpenID specification is only couple of pages. It is also designed to be used only in the web environment. The protocol itself relays to features offered by HTTP protocol, for example response status codes and request types (GET, POST). Original idea behind OpenID was to use URL of blog as an identifier. This feature is still one of the main pillars of OpenID. All identifiers in OpenID are URLs (the specification supports XRIs as well) that guarantees that each identifier is also unique and because OPs are only able to manage URLs which belong to their domain, it s not possible to cause identifier conflicts beteween providers. OpenId authentication consists of several steps [8] that are shown in Fig. 1

User RP OpenID URL OP 1. Enter OpenID 2. Discovery 3. Associate 4. Redirect to OP 5. Authenticate 6. Redirect to RP 7. Verify Figure 1: OpenID authentication steps 1. A user wants to login to RP and enters his OpenID identifier. 2. Using the entered identifier RP performs discovery operation where it lookups for necessary parameters to start the actual authentication process. OpenID supports different methods for discovery, so identifier owner can choose a method that suites best for him. After discovery process RP should known the OP endpoint URL. If this parameter is not obtained, authentication process cannot continue. 3. RP uses OP endpoint URL to form association between the two parties. This association contains a shared secret between RP and OP and is used to sign subsequent messages in this specific authentication process. 4. RP redirects user to OP endpoint. 5. OP checks whether the user is already authenticated or not and shows the login screen if necessary. 6. After successful authentication, the user is redirected back to RP. 7. RP verifies parameters received from OP using the shared secret. RP also verifies that authenticated identifier matches the one that user claimed. Obviously OP is able to authenticate only identifier which belongs to its domain. After verification RP can consider user as authenticated and perform the local authorization process if necessary. After identity is authenticated, it is possible for RP to request attributes for identity from IdP. OpenID contains an extendable Attribute Exchange protocol[7] for this purpose. Protocol is quite simple and basically it allows RP to request values for different attribute names, for example age, full name, gender and email. Actual specification defines only the protocol that should be used when requesting these attributes - it does not mention anything about the attribute names that are supported or should be used. A community based project (http://www.axschema.org/) has started to collect unofficial list of common attribute names and it seems to be currently the standard that different parties are recommended to use. Attribute exchange protocol takes account the privacy of attributes. Before OP passes attributes to RP, it checks from the user if he wants to reveal this information for the specific RP. Users choice can be stored to OP so the permission will not be asked next time the user authenticates to the same RP. OpenID also provides possibility to move from one IdP to another and still retain the original OpenID identifier. If user is in control of his own OpenID identity, he can delegate the actual authentication task to IdP of his choice. This is possible if the user is either able to modify the content of OpenId URL or if identity belongs to a provider that already supports authentication delegation (like myopenid.net). Transfer to authenticating IdP is performed during provider discovery. If RP finds certain HTTP meta-data information from OpenID URL during discovery, it will use this information as a OP Endpoint URL and as a OP-Local Identifier.

Rest of the process will be performed against this newly discovered endpoint using the local identifier, but when returning to RP, the claimed identifier will be the original one that user entered[8]. If user is interested about changing his IdP and still keep his original OpenID identity, the initial OpenID identifier must be chosen with care. Big providers like AOL, Google or Yahoo do not allow their identifiers to be authenticated by other providers. However it is possible to use identifier i.e. from myopenid.net and delegate the authentication to any other provider that the user wants to use. 5 SSO with multiple IdPs using OpenID Environment with multiple autonomous identity providers differs quite vastly from typical enterprise SSO scenario where identities are controlled by one main system. This section will discuss what are the differences between these two setups, how multiple providers can work together and what kind of issues it causes. If there are several IdPs and everyone can start their own, does this not cause possibility for identity conflict where multiple IdPs contain a user with same identifier? In identity management in general this is avoided by defining some context where identity is unique. This context is usually limited to one IdP, the actual global identity can be formed using context specific identity and namespace of the IdP. OpenID solves this problem cleverly because each identity is also a URL that clearly denotes the domain. Biggest difference between OpenID and federated SSO is that former one is missing the central concept of the latter one - circle of trust. Like previously mentioned, there is usually a trust relationship between SP and IdP. In OpenID this relationship, however, is obviously missing. Everyone can become a service provider and everyone can start acting as a identity provider. Lack of CoT in OpenID moves the trust from application level to social level[2]. To trust another person, a user must somehow verify that the person really is who he claims to be. This could be accomplished for example by contacting person with email or by some other means and verifying his OpenID identifier. In enterprise SSO the person with name Kari Helenius can be trusted to being Kari Helenius in given context because this information is obtained from IdP that is trusted in the enterprise. When there is no trust between RP and IdP, all attributes received from IdP should be considered as unqualified. The only information that can be handled as trusted is the identity. Attribute exhange protocol allows to query for the email address of the user. If IdP is for example Google, service can assume that the user is really the owner of the email address and the address can be taken to use directly without authorizing it. That kind of assumptions, however, require creating blacklists and whitelists for certain OPs (trust attribute X if it is coming from OP in list Y) that form one-way federation and is against openess of OpenID. The main problem with current status of OpenID is that even though large email providers such as Google, Microsoft, Yahoo and AOL are releasing their support for OpenID, they are only acting as OpenID providers[3]. None of them is interested to act as a relaying party because that would force them to relay to arbitrary OPs and they could not guarantee that access to their system is secured in sufficient way and availability of their service would be dependant from 3rd party. If user had chosen OP poorly, he might not be able to access his mails, because the identity provider is down temporarily or even might have closed completely[3]. 6 Evaluation and discussion From security perspective, major problem in OpenID seems to be its vulnerability for phishing[4][9]. When a user is lured to a malicious RP and he has entered his OpenID identifier, the RP - instead of redirecting to the actual OP endpoint - fetches the page at the OP endpoint and shows it to the user. When the user fills username and password fields, the RP can steal those. Marco Slot in [9] even presents a level 3 phishing attack where malicious RP simply asks for OpenID identifier and password. User who is familiar with OpenID concept notices such phishing attempt, but average user with less knowledge about the actual technology probably just fills the fields. This kind of phishing attacks are, however, more related to how the user can verify when he is at the OP pages and can securely enter his credentials. It is related to OpenID because the OpenID concept opens these new phishing possibilities. Content sharing on the Internet has gained lots of popularity in the last few years. Half of the top 10 sites in the world are related to personal content sharing[1]. Even though these sites would support OpenID, they would present another problem when users still need manage redundant copies of their social networks. A technology called Lockr[1] has been proposed to solve this issue. Lockr consists of one central LockrCenter application which stores social access control list (ACL). ACL contains public keys of allowed parties and type of relationships that are used to map the users to the protected content. A user accessing the content is required to prove his identity by using his private key. By replacing the asymmetric key security with the OpenID authentication, this solution allows centralized access right management with OpenID identities. Missing support for Single Log-Out (SLO) is also a security vulnerability in OpenID. Because there is no possibility to centrally control lifetime of user sessions, it is possible that user logs out or his session expires at OP, but still remains open at RPs. This could be an issue in environment where same PC is shared with multiple people, like in a library. If user logs out only from his OP and accidentally leaves the browser window open, the next person coming to that PC would be able to use his account at the RPs where the user still remains logged in. [6] Most of the applications require more information about the user than just an identifier. This information can be collected either from attributes that are received during authentication or by letting user input the values. Storing these values locally causes duplication of the information and forces users to maintain them manually. Current version of OpenID lacks possibility to propagate attribute modifications to RPs

which in turn causes data to get unsynchronized when user modifies it at OP. 7 Conclusions Having a common SSO method on the Internet is a huge relief for both service developers and users who are accessing these services. Currently each application must contain logic for user authentication, registration, account management and password recovery. If these actions can be delegated to some external party, it has significant effect in administrative and development costs and also generally improves the security of the service. Users benefit from the fact that they have to remember only one username/password pair that grants them access to all the services they want to use.[10] OpenID has gained lots of popularity and with popular service providers starting to support it, it seems to be coming even more popular. Its strength being open has also become its weakness. None of the large service providers are interested to act as RP if they must relay to every OP. This might lead to a federated login support where certain RPs only trust to a limited number of OPs. OpenID does not remove the fact that users are still forced to manage duplicate information in multiple services. Protocol itself guarantees to provide only the identity - all the attributes are optional and unqualified as well. If service requires any extra information about the user, it must collect that from user, validate it, if necessary, and store it locally. Protocol s vulnerability for phishing is also an issue that should be solved. Educated Internet users have probably enough knowledge to avoid it, but that does not apply to the average users. When a user is using only one account to access all services, consequences will be much worse if credentials for this account are stolen. [6] H.-K. Oh and S.-H. Jin. The security limitations of sso in openid. Advanced Communication Technology, 2008. ICACT 2008., 3:1608 1611, 2008. [7] OpenID. Attribute exchange protocol specification, 1.0 edition. http://openid.net/specs/ openid-attribute-exchange-1_0.html. [8] OpenID. OpenID specifications, 2.0 edition. http: //openid.net/developers/specs/. [9] M. Slot. Beginners guide to openid phishing. http: //marcoslot.net/apps/openid/. [10] A. Volchkov. Revisiting single sign-on: A pragmatic approach in a new context. IT Professional, 3:39 45, 2001. References [1] Amin Tootoonchian, Kiran K. Gollu, Stefan Saroiu, Yashar Ganjali and Alec Wolman. Lockr: Social access control for web 2.0. In WOSN 2008, August 2008. [2] F. Culloch. Openid and saml. Technical report, Terena EuroCAMP Stockholm, May 2008. www.terena. org/activities/eurocamp/may08/ slides/20080508-culloch-openid.pdf. [3] G. Goth. Single sign-on and social networks. IEEE distributed Systems Online, 9, 2008. [4] K. C. HwanJin Lee, InKyung Jeun and J. Song. A new anti-phishing method in openid. In The Second International Conference on Emerging Security Information, Systems and Technologies, 2008. [5] E. Maler and D. Reed. The venn of identity: Options and issues in federated identity management. Security and Privacy, IEEE, 6:16 23, 2008.