Kari Helenius
Helsinki University of Technology
[email protected]
Abstract
With new services emerging on the Internet daily, users need to manage and remember more and more user-name/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 sev-eral 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 man-ner 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 Inter-net 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 at-tributes 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 re-quired. In this paper we take a look how these attributes are shared and how this relationship is created to ensure that pri-vate 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 him-self 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 al-ways 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 authentica-tion is to perform it against the party who is claiming the identity. That however would not be very trustworthy be-cause 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. Identi-fication 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 typ-ical 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 secu-rity 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 ser-vices. 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 au-thoritires, the related attributes are usually as well. However,
it is also possible that authenticated identity can contain non-authenticated 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 ser-vices are released on the Internet all the time and more and more applications inside corporations are used with regu-lar web browser instead of being separate desktop applica-tions. Running the applications centrally at the server re-duces administrative and maintenance costs dramatically, be-cause only one instance of application needs to maintained. Usually each of these applications require users to authenti-cate into them separately forcing people to remember sepa-rate 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 dif-ferent 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 appli-cations, 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 dur-ing the last few years Security Assesrtion Markup Language (SAML) maintained by OASIS has become the standard pro-tocol [5].
SAML is a XML based framework designed to pass iden-tity information between different parties in a secure man-ner. It has been designed as a flexible and extendable frame-work 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 us-ing 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 us-ing centrally managed account information and performus-ing 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 authenti-cate 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 cir-cle of trust (CoT). Mutual authentication is used inside CoT
between parties to assure that only trusted SPs are authenti-cating users through IdP and that only trusted IdP provides information about the user. Because of CoT, all the informa-tion provided by IdP can be considered trusted.
Because CoT allows IdP to recognize which SP is request-ing attributes, it is possible to limit privacy of certain at-tributes. Enterprise might want to integrate some 3rd party SP as a part of their CoT allowing users to access this SP us-ing their existus-ing user accounts. In such case company might limit the accessible attributes for that service to only neces-sary 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 se-vere decrease in performance. Attribute propagation is used to synchronize the parameters between IdP and SP. When at-tributes are modfied in IdP, a special message with new val-ues is sent to SP so it can update its existing valval-ues 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 se-quentially 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 com-ment, 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 spec-ification 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 specifica-tion supports XRIs as well) that guarantees that each iden-tifier is also unique and because OPs are only able to man-age 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
U s e r R P 1 . E n t e r O p e n I D O p e n I D U R L 2 . D i s c o v e r y O P 3 . A s s o c i a t e 4 . R e d i r e c t t o O P 5 . A u t h e n t i c a t e 6 . R e d i r e c t t o R P 7 . V e r i f y
Figure 1: OpenID authentication steps
1. A user wants to login to RP and enters his OpenID iden-tifier.
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. Af-ter 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 se-cret 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 identi-fier 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 au-thenticated and perform the local authorization process if necessary.
After identity is authenticated, it is possible for RP to re-quest 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 at-tributes - 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 col-lect unofficial list of common attribute names and it seems to be currently the standard that different parties are recom-mended 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 possi-ble if the user is either apossi-ble to modify the content of OpenId URL or if identity belongs to a provider that already sup-ports authentication delegation (like myopenid.net). Trans-fer to authenticating IdP is performed during provider dis-covery. If RP finds certain HTTP meta-data information from OpenID URL during discovery, it will use this infor-mation as a OP Endpoint URL and as a OP-Local Identifier.
Rest of the process will be performed against this newly dis-covered endpoint using the local identifier, but when return-ing 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 iden-tity management in general this is avoided by defining some context where identity is unique. This context is usually lim-ited 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 usu-ally 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 iden-tity. 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 authoriz-ing it. That kind of assumptions, however, require creatauthoriz-ing 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,
Mi-crosoft, 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 iden-tifier, the RP - instead of redirecting to the actual OP end-point - fetches the page at the OP endend-point 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 prob-ably 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 popular-ity 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 replac-ing the asymmetric key security with the OpenID authenti-cation, this solution allows centralized access right manage-ment with OpenID identities.
Missing support for Single Log-Out (SLO) is also a secu-rity 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 re-mains open at RPs. This could be an issue in environment where same PC is shared with multiple people, like in a li-brary. 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 col-lected either from attributes that are received during authen-tication or by letting user input the values. Storing these val-ues 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 re-lief for both service developers and users who are access-ing these services. Currently each application must contain logic for user authentication, registration, account manage-ment and password recovery. If these actions can be dele-gated to some external party, it has significant effect in ad-ministrative and development costs and also generally im-proves 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 ser-vice 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 inter-ested 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. Pro-tocol itself guarantees to provide only the identity - all the attributes are optional and unqualified as well. If service re-quires 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.
References
[1] Amin Tootoonchian, Kiran K. Gollu, Stefan Saroiu, Yashar Ganjali and Alec Wolman. Lockr: Social ac-cess 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
Interna-tional 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.
[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 specifica-tion, 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.
