User Centric Authentication for Web Applications

Michal Prochazka, Daniel Kouril, Ludek MatyskaCESNET z.s.p.o.,Zikova 4, 160 00 Praha 6 and

Masaryk University, Botanicka 68a, 602 00 BrnoCzech Republic

{michalp,kouril,ludek}@ics.muni.cz

ABSTRACT

Due to its large penetration and ease of use, the web en-vironment provides a platform that enables collaborationamong people working on a joint topic. Regardless of theactual focus of collaborating groups, security is very of-ten a key aspect of such an environment. Provision of theproper level of authentication and access control is a ne-cessity in almost any real world deployment of collabo-rative tools. The growing number of collaborating peo-ple also increases the overheads of the management of theusers and their identities, especially when people from mul-tiple institutions are involved. Current approaches to ad-dress these issues try to make use of the federated identitymanagement, which makes it possible to utilize the existingidentity management systems and to link them with the ser-vice providers. However promising the federated modelsare, they also show some drawbacks that render the sys-tems less usable than intended. In this paper we provide asummary of the weaknesses and, following that, we intro-duce another model that places the user as the main part ofthe infrastructure. The architecture moves the managementof users’ attributes closely to their owner and provides ascalable infrastructure enabling a dynamic trust establish-ment.

KEYWORDS: Web security, identity federations, usercentric model.

1. INTRODUCTION

Collaboration among people or teams needs proper com-munication channels established between all the partici-pants. Following particular requirements of the communi-cating parties, proper security precautions must be also ap-plied, which will ensure that the required level of security is

achieved and retained. Usually, very basic expectations re-quire that authentication and authorization is performed, aswell as basic message protection (e.g., using encryption).

Since the web technology is very often used by collaborat-ing groups to their coordination and mutual communica-tion, the security of web-based systems is crucial for col-laborating communities. Despite several possibilities of-fered by current technology, it is still somewhat challengingto select an authentication system that suits both users andservice providers due to an implicit conflict between theirnotions and requirements. While the former prefer sim-plicity of the process, the latter often require too complexauthentication procedures. Ironically, raising the bar leadsrather to weakening of the whole system due to the usersinventing ways to bypass it (e.g., the infamous sticky noteswith password fastened to monitors). Apart from authen-tication, proper access control is often required, includingsupport for various dynamic scenarios. For instance, in or-der to handle dynamic groups of users, where membershipschange a lot, an efficient way is needed to decide whetheror not a given user is a member of a particular group. Thereare multiple mechanisms to achieve such authorization sup-port, however, they often introduce additional overheads orare not able to be integrated with existing solutions. Forexample, a group of students enrolled in a class could beidentified easily if an access to a study agenda is given. Asthis is usually not the case, teachers (or class members) pro-viding study material to the pupils have to set up their ownidentity management systems. While very simplified, sim-ilar scenarios are very common nowadays and introduceadditional overheads and possible inaccuracies, which de-creases the system’s usability and security.

A possible solution to address the problems outlined aboveis presented by federated identity management, which hasemerged recently. The model of identity federations makes

67978-1-4244-6622-1/10/$26.00 ©2010 IEEE

the authentication step easy for common users, mainlysince it does not require the users to register new authen-tication credentials with each new service. Instead, it uti-lizes the existing identity management systems and allowsthem to hand over authentication decision to the end ser-vices. The model also helps to improve the authorizationstep, since various attributes about the authenticated usercan be passed on to the service. The model of federatedauthentication has became very popular and a wide rangeof providers of identities and services have formed togethervarious federations. Despite clear advantages of the exist-ing federation models, there are also a lot of weaknessesinherent in them, which can complicate their utilization inthe future. In this paper, we provide an overview of theweaknesses and describe a design of a system that addressthe shortcomings.

The rest of the paper is organized as follows. First, we de-scribe the related work summarizing technologies used forweb authentication. Then, we provide a design of the Aditisystem as our main contribution, where all its componentsare described.

2. RELATED WORK

As indicated in the previous section, there are multiplemechanisms for authentication on the web. The mostwidely used methods utilize a pair of the user’s login nameand password, which is registered with the web server. De-spite their simplicity, plain passwords pose issues that mustbe addressed properly. Without an additional infrastructureit is not possible to implement a Single Sign-On (SSO) so-lution, which is a key requirement for most web applica-tions. Passwords also provide only authentication withoutany support for subsequent access control, e.g., revealingadditional information about the user.

Another option to authenticate users against web-based ap-plications is using the SSL/TLS protocol suite [7] and clientX.509 certificates. Compared to passwords, this methodacts better in several aspects. The weakest point of us-ing users’ X.509 certificate is the private key management,since users often neglect proper handling of files with sensi-tive keys. Some areas of the management can be improvedby means of smart cards but they introduce other problems,like application readiness and appropriate support of usersutilizing the cards. Unlike passwords, digital certificatescan contain additional information about their bearer butthese are too generic and not suitable for authorization de-cisions.

In order to provide an SSO approach, a more sophisticatedinfrastructure must be established, especially if it would

overcome boundaries between multiple organizations. Afederated identity management is a possible solution that isbeing adopted by a large number of institutions nowadays.An identity federation is an infrastructure connecting iden-tity management systems from different institutions andservices providers, which require user authentication. Iden-tity federations enable to share information about the usersthrough a standardized protocol that is accepted by everyparty in the federation. Every organization participating inthe federation manages its users by a local user manage-ment system. An identity provider (IdP) service is built ontop of such an existing user management system, providingan interface to access authentication information and otherattributes about the user, like name, affiliation and uniqueidentifier. Every service provider (SP) in the federation canobtain this information by calling the IdP service. SPs pro-cess the data returned by the user’s home IdP and use it tomake access control decisions. Before users are allowed touse a service, they have to present a set of attributes issuedby their IdP. These attributes are provided to users or to aservice working on their behalf upon proper authenticationof the user with the IdP.

A user visiting a federated service is first checked and ifno authentication information is known to the SP, the useris redirected to his or her IdP web page. After the userhas successfully authenticated with the IdP, the IdP createsa response containing confirmation of successful authenti-cation and additional information about the user. The re-sponse is then sent to the SP, which verifies the validity ofthe response and extracts information about the user. Fi-nally, the SP makes an authorization decision and lets theuser in or not. The same principle is applyied when theuser accesses other SPs. Therefore, the user needs to main-tain only one account and one set of credentials for all SPswithin the federations. These credentials are only managedon the IdP and not available to SPs, which enhances theirsecurity.

The next subsections describe the most known and usedmiddleware stacks that implement the concept of identityfederations.

2.1. Shibboleth

The leading middleware for building identity federations inthe higher education sphere is Shibboleth [1]. The currentversion of Shibboleth is built upon the Security AssertionsMark-up Language version 2 (SAML2) [2], which is anXML-based specification to define a common XML frame-work for exchanging authentication, authorization and at-tribute assertions between entities. Shibboleth defines threeadditional entities besides identity and service provider:discovery service, metadata and federation operator. The

68

discovery service is used by the users to locate their homeorganization IdP. With the discovery service, the SP doesnot redirect the users directly to the IdP, but to the dis-covery service page, where the user then selects his or herIdP. Metadata is an XML based document containing infor-mation about all entities within the federation. Obviously,metadata has to be properly managed. All the parties haveto be listed, and each party has to have up-to-date copy ofmetadata, in order to be able to create a communicationlink to another entity as well as to verify messages receivedfrom other entities. Metadata is usually maintained by thefederation operator, which also defines the federation poli-cies and introduces new SPs and IdPs. Every IdP can definean attribute release policy for each SP within the federation.The attribute release policy defines which attributes aboutthe user can be released to a particular SP. Therefore, anIdP releases different sets of the user’s attributes to differ-ent SPs. The set allowed is defined in an agreement be-tween the SP and IdP or between the IdP and the federationoperator. Therefore, the user is not the one who decideswhich attributes will be released. The user can only acceptor decline releasing of the set as a whole. Because the de-cision is not left to the user, the IdP has to obey appropriateprivacy laws.

It is certainly not possible to establish a single big federa-tion registering all SPs and IdPs from the globe, for severalreasons including technical and administrative severity andpolitical will. Therefore, we can certainly expect a num-ber of federations to emerge in the future, which will haveconsequences for the users and SP operators as well. If theoperator of an SP wants to provide its services to multi-ple federations, they need to negotiate a policy and techni-cal details with each federation operator. Because the fed-eration operators change the technical specifications fromtime to time, the SP needs to maintain a configuration foreach federation separately. Also, the SP has to implementa guidepost, where a user can select his or her federationfrom. That could be misleading for the user, especially ifthey have accounts on IdPs in multiple federations. Thesole fact that a user can have multiple identities (i.e., ac-counts on multiple IdPs) is also misleading for commonusers, since they have to maintain multiple credentials, se-lect from multiple identifiers, etc. Such an arrangementcannot be avoided nowadays, since in order to allow theuser to access services in the federation it is inevitable forthe user to obtain an account on an IdP in the federation,too. Having multiple such identities will make the users’life harder, especially when the number of federations in-creases.

Identity federations based on Shibboleth are too restrictivein several cases. We have to find a different solution to

build a federation, where the provisioning of the IdPs andSPs will not require any registration at a centrally managedpoint. Also, users should not have any redundant accountsand should be able to combine the attributes from differentIdPs into one set that is presented to the SP.

2.2. OpenID

OpenID [3] is an open community-driven platform that rep-resents user-centric and URI-based identity systems. User-centric federations leave all the management of the useraccount up to the user. The user decides who will man-age his or her account and which attributes will be releasedabout him or her. URI-based identity systems use an URI asan identity identification. OpenID is a lightweight HTTP-based URL authentication protocol. Currently it supportsXRIs [4] as user identifiers, uses Yadis XRDS [5] docu-ments for IdP discovery, adds stronger security, and sup-ports both public and private identifiers. OpenID works alittle bit differently from the Shibboleth. The users entertheir identifiers directly at the SP web page. Each user’sidentifier contains information where the user’s IdP is lo-cated. In order to not bind the identity identifier with aspecific IdP, OpenID uses a mediator, which is a web pagedefining where the user’s IdP is really located. The userthen uses the address of the mediator instead of an identityidentifier.

OpenID is completely decentralized and no central author-ity need to approve or register SPs and IdPs. An end usercan freely choose which OpenID IdP to use, and can pre-serve their identifier if they switch between OpenID IdPs.

Unfortunately, OpenID has several security issues de-scribed in paper [6], with the most critical being missingprotection against phishing, DNS and man-in-the-middleattacks. Less critical, but still a severe security related prob-lem is that the OpenID protocol does not specify how todiscover IdPs in advance or how to determine IdPs’ trust-worthiness. Therefore, there is missing validation of thesource of the attributes. And, as in other identity federa-tions models, attributes from one IdP cannot be combinedwith attributes from others IdPs.

2.3. CardSpace

The Microsoft CardSpace [14] (also known under its co-dename InfoCard [13]) is a little bit different architecturefrom the previous ones, it provides a virtual identity meta-system. CardSpace does not prescribe any particular pro-tocol for exchanging the authentication tokens and user’sattributes between IdPs and SPs. CardSpace was designedfrom the user’s perspective. The major component is a cardselector, which is a client application managing user’s iden-

69

tity cards. Each card represents a different identity and canbe issued by a third party as well as the users themselves.When the user accesses a CardSpace enabled SP, the cardselector will pops up on the desktop and the user selects theidentity they want to supply to the SP. If the card is man-aged by an IdP, a request from the SP is passed to the IdPand user is requested to authenticate with the IdP. The IdPand SP have to know each other in advance, in order to usethe same format of the security token.

CardSpace is built on the top of the Web Service Proto-col Stack, an open set of XML-based protocols, includingWS-Security, WS-Trust, WS-MetadaExchange and WS-SecurityPolicy. CardSpace is token-format-agnostic, there-fore the IdPs and SPs can exchange security tokens andattributes, for example, in the SAML, Kerberos or OpenIDmessage format.

2.4. Higgins

Higgins [12] is a software infrastructure, which allows tointegrate and leverage multiple identity protocols for theSPs and IdPs. It works with all widely used digital iden-tity protocols, including WS-Trust, OpenID, SAML, XDI,LDAP. Just like CardSpace, Higgins uses identity cards,but it goes much further. Users can use the Personal DataAgent1 to store their own digital identities in a remote ser-vice in order to make them available from different loca-tions. Higgins also introduced a new type of a card, a re-lationship card, which can combine assertions issued by anIdP and own assertions. Main disadvantages of Higgins area missing trust management among the SPs and IdPs andimpossibility to combine assertions from more IdPs.

3. ADITI

User centric identity federations represented by OpenIDhave several advantages compared to common identity fed-erations represented by Shibboleth. Unfortunately, OpenIddoes not provide solutions for basic requirements on theuser centric identity federations, like complete user con-trol over the user’s data, the ability to verify trustworthi-ness of the attributes issued by the IdP, the ability to com-bine attributes from different IdPs into one set, resistanceagainst phishing and man-in-the-middle attacks. Therefore,we have designed a new system for user centric identityfederations, which we have called Aditi2.

3.1. Aditi System Design

The design of the Aditi system (see Figure 1) tries to mimicordinary behavior of a person in a society, where institu-

1http://wiki.eclipse.org/Personal Data Agent Overview2Aditi means “boundless, entire” or “freedom, security” in Sanskrit.

tions or companies issue cards with the user’s informationand the user decides whether to show the card to someoneelse. The receiver of the card decides whether he or shetrusts the card, or more precisely, trusts the issuer of thecard, while the issuer of the card (IdP) does not care aboutwhom it is actually presented.

Figure 1. Aditi Design

Traditional identity federations consist of three or four en-tities: service providers, identity providers, users and op-tionally metadata providers. In order to provide more func-tionality, the Aditi system (in Fig. 1) enhances the standardfederated model with new IdP and SP components operateddirectly by the user (user IdP and user SP, respectively)to provide an interface between the user and the federa-tion. Utilizing the User IdP (uIdP) the user maintains theattributes issued to them by other IdP. The attributes aremanaged as separate cards containg individual values. Theuser can use the attributes to create their own cards that willrepresent different users’ digital identities. Digital cards areanalogous to the physical cards like payment or nationalID cards. A user can provide the created cards through theuIdP to the SPs. Compared to the reality, a user can selectonly the subset of attributes (information) from the cardthat will be exposed to the SP, or can combine the attributesfrom different IdPs. A component, that helps useris man-age digital cards and attributes is called card selector. Thecard selector is responsible for requesting attributes fromthe IdPs and for preparing the set of attributes, which willbe sent by the uIdP to the SP. Card selector in the Aditiis from the user’s point of view similar to the CardSpacecard selector, but in the inside it works completely differ-ent. CardsSpace card selector has a cards as a representa-tion of the identity at the IdP, but the Aditi uses cards as acontainer of the attributes acquired from the IdPs.

Compared to CardSpace and Higgins, which use cards aswell, Aditi provides complete user’s control over their at-tributes and the user can change the set of the attributessent from the IdP to the SP arbitrarily. Even more, users

70

can combine attributes from different IdPs. In Aditi, a userdoes not act as a proxy passing attributes from an IdP to SP,but is a full featured entity, which can manipulate with theattributes. Compared to CardSpace, Aditi does not requireany trust relationship established between the IdP and SPs,the IdP does not need to know anything about the SPs.

Shibboleth IdPs release attributes directly to the SP, there-fore the IdP has to have an agreement from the user and hasto obey the privacy laws. OpenID users can decide whichattributes will be released by the IdP. Aditi implements adifferent approach. The users download all their attributesfrom the IdPs to the card selector, then all the operationswith the attributes are under full control of the user. In thisscenario, the IdP does not have any direct relationship withthe SP; the user’s home organization IdP will only commu-nicate with the uSP. Therefore, it is not restricted by theprivacy law and user’s agreements. The IdP has to digitallysign each issued attribute, so the SP can verify the issuer ofthe attribute.

This setup allows for removal the direct communicationlink between the organizational IdPs and SPs, and makesthe trust link between the IdPs and SPs only one way. InAditi the SP has to trust the IdP, but not the other wayround. The IdPs have only one communication link to theuser’s SP. When the user needs attributes from his or herhome organization IdP, he or she simply authenticates withthe IdP as in a common identity federation, making the IdPrelease all attributes about the user to the user’s SP. Theattributes are digitally signed by the IdP, thus any SP cancheck the origin of the attributes and their integrity. Theuser can repeat this step with all the IdPs where they havean account. The user’s SP then holds the user’s attributesfrom different IdPs at a single location. The user can eithertake attributes from the IdP or they can create their own setof attributes by combining these attributes together. Theuser can also add their own attributes. The attributes man-aged on a uSP yields multiple identites of the user. A usercontacting an SP in our model has to select one of the dig-ital identities and send the appropriate attributes to the SP.Like in the real world, the SP needs to know who issued theattributes about the user. Therefore, the SP has the abilityto determine the level of trust of the IdPs. The SP cate-gorizes the IdPs to different sets, distinguished by the trustlevel.

Aditi also simplifies the communication flow between theIdP, user and SP. In all above mentioned middlewares theIdP has to be contacted before accessing the SP. In Aditi,the user gets all attributes from the IdP and stores themlocally, therefore every consequent communication withthe SPs does not involve communication with the IdPs.

From the performance point of view, the IdPs are contactedfewer times since the communication is moved to the clientside and performed in advance. Furthermore, compared toOpenID and Shibboleth, Aditi does not require the HTTPredirection functionality or cookies, see Section 3.4.

Since Aditi enhances the existing models, it is obvious thatit provides all functionality as the original models do. Inaddition, we have solved the issue of introducing of the SPto the identity federation; SP can join the federation with-out any negotiations made with the IdPs or any other party,like the metadata operator. We have removed the communi-cation line between the IdP and SP, except that one betweenthe user’s SP and IdP. The IdPs and SPs are part of the iden-tity federation without being listed in any central registry,furthermore, the IdPs do not have any connection with SPs.Therefore, the model does not present any obstacles, whichcan limit the scalability. Our model decreases the commu-nication cost of a service request, since no redirections areinvolved and all necessary attributes can be supplied by theuser in a single message.

The problem with missing complete user’s control overtheir data transfered from the IdPs to SPs is also addressed.All the data from the organizationals’ IdPs is sent to theuser’s SP, which processes the data. The data is then passedon to the user’s IdP, which in turn communicates with theSPs. Revocation of the assertions is solved identically asin common identity federation; simply, it is not needed, be-cause the assertions has a limited lifetime. Finally, the cre-ation of the IdPs’ hierarchy can be done within our model.The IdPs can optionally maintain the same sets of the trustlevels as the SPs. If the user provides valid assertions is-sued by another trusted IdP to the IdP, the IdP then canissue assertion without requiring the user to authenticateusing IdP’s authentication mechanism.

3.2. Trust Management in Aditi

In order to help the SPs to find out the trustworthiness ofan IdP, a system of trust has to be defined. An identity fed-erations’ environment is quite dynamic, with SPs and IdPsentering and leaving it from time to time. Therefore, wecannot use any static data set for measuring the trust that isused nowadays. We have designed a trust network, whichwill be used to propagate and gather information about en-tities to evaluate the IdP’s trust level. The trust (depictedin Fig.2) in Aditi is based on one-way trust like in the realworld. The companies or institutions that need to check theidentity of a person usually require the client’s national IDcard, so they trust the issuer of the card without the issuerhaving to know them. An IdP issuing attributes can be iden-tified in various ways, therefore the SP is equipped with a

71

new component called Trust Processor, which is connectedto the Aditi Trust Network.

Figure 2. Aditi Trust

3.2.1. Aditi Trust NetworkThe “Aditi Trust Network”, depicted in Figure 3, is a com-pletely decentralized network, which models the relation-ships between the SPs and IdPs. We intend to employ thepeer-to-peer concept to build the trust network. The enti-ties (SPs and IdPs) have to be able to organize themselvesinto groups within the trust network, with each group defin-ing different levels of trust. The entities within one grouptrust each other and every entity can be bound to multiplegroups. An entity can contact another one and ask it for itsidentification or information about the entities which areknown to it. The obtained information is used for compu-tation of the trust level.

Figure 3. Aditi Trust Network

3.2.2. Aditi Trust ProcessorThe “Trust Processor” depicted in Figure 4 gathers infor-mation from various sources and computes the level of trustfor each issuer (IdP). The trust processor provides a set ofTrust Modules for the trust level computation. Some of themodules are exact, like a PKI one, where trust is defined

by design. Other modules use methodology from the rep-utation systems and utilize the trust network through theTrust Network Node to get the data. A very promising so-lution for the reputation modules is provided in [8], wherethe author proposed using hypergraphs to build a reputa-tion system for peer-to-peer networks. We plan to adoptthis approach in our trust network and trust processor.

Figure 4. Aditi Trust Processor

The trust processor can be configured through the Config-uration module. The user can set the local policy and addexceptions, which will override the data received from thetrust network. The configuration module also contains con-figuration values used by other modules (see the dashedline). The trust engine implements the computation of thetrust level, which is used for decisions if the attributes aboutthe user are from the trusted IdP.

The trust processor can also be used by the IdP to obtainthe trust level of other IdPs. A hierarchy of the IdPs willcertainly decrease a number of the credentials that a userneeds to maintain. The approach is again taken over fromreal life. For example, banks accept the national ID cardsas a proof of identity (authentication) and then issue a pay-ment card, which is a different proof of identity. Generally,one IdP accepts attributes from a different trusted IdP as asufficient proof of identity instead of requiring use of thecredentials (e.g., username and password).

72

3.3. Aditi Complementary Features

Today’s identity federations are only focused on the webenvironment heavily utilizing the features of the HTTP pro-tocol and cookies. Although more and more services be-comes available through the web browser, there still re-mains a big portion of desktop and distributed applicationswhich require user’s authentication. Thus, we have to alsotake into account non-web environments. Recently, wehave done research in this field [10]. We used the PKI [9]as an authentication system. Since PKI is often used innon-web applications, we have decided to use an on-linecertificate authority (on-line CA) as a service provider inan identity federation. The On-line CA gets the user’s at-tributes from the IdP and puts them into a newly createdcertificate as an extension. This certificate can then be usedin a non-web environment, where services can extract theattributes. Generally speaking, an on-line CA presents abridge between the web and non-web domains. It is quiteeasy to integrate this functionality with Aditi, too. As theuser operates uSP and uIdP, he or she can operate anothermodule, which will implement the credentials transforma-tion to allow the users access other services, too. The cre-dentials transformations are described in [11].

A new regulation approved by the Council of the EuropeanUnion requires the user’s consent when a web server wantsto store cookies in the user’s browser. If some EU memberstate adopts this regulation strictly, it will cause a problemsfor today’s identity federation frameworks, because mostof them use cookies. In Aditi, where the user operates theuSP and uIdP, we do not need to use cookies at all. TheuIdP can send a complete set of attributes in every requestto the SP.

Scalability, which is a problem of Shibboleth, is solved bythe design itself, since there is no central point in the pro-posed model. Provisioning of the new IdP or SP does notrequire any communication with other entities in the feder-ation. No entity in the federation needs to know the wholestate of the federation and the process of transferring at-tributes from the IdP to the SP only involves these entities.The trust network also does not have scalability problems,because it is built on the basis of a decentralized peer-to-peer network.

4. CONCLUSION

In this paper we have presented an alternative model ofidentity management, which can be used to implement anefficient identity federation. A federation based on theAditi concept does not have issues visible in other con-temporary solutions and can be used as an integrating el-

ement connecting multiple different SPs with different ac-cess policies.

The user-centric approach moving the attribute handling tothe user makes it possible to maintain attributes from mul-tiple IdPs, which ease the user’s involvement in multiplefederations. The model also decreases the communicationoverheads of particular application requests and their com-plexity, which allows to develop light-weight clients thatdo not have to understand complex features of the HTTPprotocol.

Since the trust management is not sufficient enough in cur-rent federations, we have designed a new model allowingthe involved parties to compute a trust level between eachother. Trust can be determined by each user separately giv-ing them full control over the environemnt and servicesthey communicate with.

ACKNOWLEDGMENT

The work has been supported by the research intent “Op-tical Network of National Research and Its New Applica-tions” (MSM 6383917201) of the Ministry of Education ofthe Czech Republic.

We also acknowledge the support of the project102/09/H042 “Mathematical and Engineering Approachesto Developing Reliable and Secure Concurrent and Dis-tributed Computer Systems” of the Czech Science Foun-dation.

REFERENCES

[1] S. Cantor, S. Carmody, M. Erdos, K. Hazelton, W. Hoehn,R. Morgan, T. Scavo and D. Wasley, Shibboleth Architecture,Protocols and Profiles, Internet2, 2005.

[2] S. Cantor, J. Kemp, R. Philpott, E. Maler and et al., Asser-tions and Protocols for the OASIS Security Assertion MarkupLanguage (SAML) V2.0, OASIS, 2005.

[3] D. Recordon and D. Reed, “OpenID 2.0: a platform foruser-centric identity management”, DIM ’06: Proceedings ofthe second ACM workshop on Digital identity management,Alexandria, Virginia, USA, 2006.

[4] D. Reed, D. McAlpin, P. Davis, N. Sakimura, M. Lindelseeand G. Wachob, Extensible Resource Identifier (XRI) SyntaxV2.0, OASIS, 2005.

[5] J. Miller, “Yadis specification”, Yadis [website], March,2006, Available: http://yadis.org.

[6] H.K. Oh and S.H. Jin, “The Security Limitations of SSO inOpenID”, ICACT 2008: 10th International Conference on

73

Advanced Communication Technology, Phoenix Park, Ko-rea, 2008.

[7] T. Dierks, E. Rescorla. “The Transport Layer Security (TLS)Protocol – Version 1.2”, IETF RFC 5246. August 2008.

[8] R. Spanek, “Self-organizing and Self-monitoring SecurityModel for Dynamic Distributed Environments”, PhD thesis,Technical University of Liberec, 2008.

[9] ITU-T Recommendation X.509: Information technology—Open Systems Interconnection—The Directory: Public-keyand attribute certificate frameworks, ITU, 2005.

[10] M. Prochazka, L. Matyska, E. Hladka, D. Kouril and P.Holub, “Transparent Security for Collaborative Environ-ments”, The 3rd International Conference on CollaborativeComputing: Networking, Applications and Worksharing,White Plains, New York, 2007.

[11] D. Kouril and M. Prochazka, “Survey of AuthenticationMechanisms for Grids”,CESNET Conference 2008, Prague,Czech Republic, 2008.

[12] “Higgins: Open Source Identity Framework”,Higgins [website], February, 2010, Available:http://www.eclipse.org/higgins/.

[13] K. Brown, “A First Look at InfoCard”, MSDN Magazine,Vol. 21, No. 4, 2006.

[14] D. Chappell, “Introducing Windows CardSpace”,Microsoft MSDN [website], 2006, Available:http://msdn.microsoft.com/en-us/library/aa480189.aspx.

74