SECURITY AND COMMUNICATION NETWORKS Security Comm. Networks 2016; 9:2843–2860 Published online 13 February 2015 in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/sec.1202
SPECIAL ISSUE PAPER
Constructing authentication web in cloud computing Gansen Zhao1 *, Zhongjie Ba2 , Xinming Wang1,2 , Feng Zhang3 , Changqin Huang1 and Yong Tang1 1 2 3
School of Computer Science, South China Normal University, Guangzhou, China School of Software, Sun Yat-sen University, Guangzhou, China China University of Geosciences, Wuhan, China
ABSTRACT Cloud computing offers a cheap and efficient solution for the deployment of web applications. It results in a big increase of the number of service provider. Users hold multiple identities for using services from different domains. The openness of public clouds requires the authentication system to accept user identities from various domains and to support hybrid authentication protocols. This work proposes a cross-domain single sign-on mechanism to address the preceding issues and makes a formal mathematical model to analyze the security issues of the proposed mechanism’s authentication architecture; furthermore, an algorithm is proposed to detect the authentication architecture’s weak vertex whose failure would lead to a partial failure in the architecture. The proposed mechanism allows service providers to verify user identities in a decentralized way and allows users to unify their identities from various domains in a safe way. The verification process used in this mechanism is able to support hybrid authentication protocols as well as to accelerate the verification of credentials by eliminating single point of failure and single-point bottleneck. Copyright © 2015 John Wiley & Sons, Ltd. KEYWORDS cloud computing; single sign-on; cross domain; identity unification; hybrid authentication protocol *Correspondence Gansen Zhao, School of Computer Science, South China Normal University, Guangzhou, China. E-mail:
[email protected]
1. INTRODUCTION With the proliferation of cloud services, most services are now open for cross-domain access. Users are able to access different services from outside their own domains and services accept users from different domains simultaneously. This development brings in several issues. (1) Cross-domain authentication. To be accessible cross the boundary of management domains, cloud services should be able to authenticate users from other management domains. (2) Compatibility of protocols. To deal with management domains, running different authentication protocols, cloud services should be compatible with different authentication protocols. (3) Performance. Cross-domain access leads to an explosive growth of subscribers of cloud services. The authentication systems of the cloud services should be able to support high-concurrency authentication process. Existing single sign-on (SSO) systems allow users to log-on once and access multiple times. But existing SSO
Copyright © 2015 John Wiley & Sons, Ltd.
mechanisms fail to tackle the preceding issues at least in four aspects. Firstly, most SSO mechanisms assume that users and service providers (SPs) are under the same SSO identity management domain where users could trust the SPs completely. Secondly, some SSO mechanisms rely exclusively on the SSO servers to verify credentials. This architecture leads to a bottleneck in performance and single point of failure and therefore limits the scalability of these mechanisms. Thirdly, most SSO mechanisms are protocol specific, and only the specific authentication protocol can be integrated into the system. But the authentication protocols used in the involved domains are usually different, which perplex the cross-domain authentication process. Finally, most SSO mechanisms find it difficult to unify users’ identities. The aforementioned authentication issues have created an obstacle for the promotion of cloud services, not to mention the large-scale deployment of clouds. This work proposed a cross-domain SSO mechanism to address the preceding issues. The proposed mechanism 2843
G. Zhao et al.
Authentication web in cloud
is able to perform authentication process between individuals under weak trust relationship, which is a more practical assumption on the relations between different management domains. Considering the particularity of cross-domain authentication, the identity verification process in this mechanism uses a relying mechanism to support hybrid authentication protocols and decentralized identity verification. Because most of the users already have a large number of identities issued by various domains, the proposed authentication mechanism introduced a protocol to unify the users’ identities, and therefore, they can use one single identity to obtain all the resources, which belong to their existing identities. The authentication architecture of the proposed mechanism is modeled by a digraph, and a formal analysis of SSO and single point of failure is processed on the basis of that digraph. The rest of this paper is organized as follows. Section 2 gives a scenario of this research and identifies the related challenges. Section 3 reviews existing work on SSO. Section 4 presents the architecture and proposes a formal mathematical model to support it. Section 5 conducts a security analysis on the basis of the proposed model. Section 6 proposes a decentralized verification mechanism to address the issue of single point of failure. Section 7 proposes a secure identity unification mechanism. Section 8 articulates a cross-domain authentication protocol. Section 9 concludes this research.
2. SCENARIO AND CHALLENGES 2.1. Scenario Cloud computing gives the SPs a cheap and efficient solution to deploy their services on clouds. This promotes the adoption of clouds, and number of SPs increases rapidly. However, most of the cloud services belong to different management domains, which cause a major issue for users’ identities management. When using clouds, services are expected to be accessible cross the boundary of management domains. This leads to the scenario described in Figure 1. In this scenario, one user might hold various identities from different management domains, and he or she should be able to use a single identity to authenticate himself or herself to various management domains. The SPs in this scenario should be able to accept user identities from other management domains even if they use different authentication protocols. This authentication scenario’s properties can be summarized as follows: (1) Large number of services and SPs: With the proliferation of cloud computing, the up-front commitment of cloud users is eliminated, even a small group can deploy their services on clouds. This situation gives 2844
a huge boost to the increase of the number of service and SP. (2) High-frequency cross-domain authentication: Users would like to use a single identity to access services from different domains. SPs accept user identities issued by another management domain, which lead to a cross-domain authentication. (3) Multiple management domains using different authentication protocols: Authentication protocols are normally chosen based on the special requirement of the management domain. Different management domains could have different authentication protocols. 2.2. Challenge This authentication scenario brings in several challenges to the construction of a suitable authentication mechanism. The main challenges of this work are as follows: Compatibility of different authentication protocols. The authentication scenario includes multiple management domains using different authentication protocols. An appropriate authentication mechanism is expected to accept identities issued by different providers with different protocols. Secure and high-performance cross-domain authentication. Cross-domain authentication is an authentication process performed by at least two management domains, which means that the number of involved individuals in cross-domain authentication is much larger than intradomain authentication. The increase of the involved individual and the lack of central authority bring in a huge challenge to the security and performance of the system. Privacy preserving identity unification policy. Identity unification is a process that unifies a user’s identity so that he or she could use one identity to access all the resources he or she is entitled to. Formal security analysis. Multiple management domains perplex the authentication architecture, which makes security analysis harder, such as single point of failure, partial failure and the protection of the users’ privacy.
3. RELATED WORKS 3.1. Single sign-on Single sign-on systems try to reduce the number of times of user authentication when they need to access multiple resources or access a resource multiple times. The extensive research interests on SSO result in many different kinds of definition: (1) Single sign-on enables users to authenticate themselves only once and then they can log-in to the serSecurity Comm. Networks 2016; 9:2843–2860 © 2015 John Wiley & Sons, Ltd. DOI: 10.1002/sec
G. Zhao et al.
Authentication web in cloud
Figure 1. Authentication scenario. IDP, identity provider; SP, service provider.
vices they subsequently use without further manual interaction [1]. (2) Single sign-on aims to solve security problems by letting individuals log-in to many Internet services while authenticating only once or at least always in the same way [2]. (3) Single sign-on is the ability for a user to authenticate once to a single authentication authority and then access other protected resources without reauthentication [3]. (4) Single sign-on protocols enable companies to establish a federated environment in which clients sign in the system once and yet are able to access to services offered by different companies [4]. 3.2. Cross-domain single sign-on
By using a reasonable distributed architecture, OpenID is able to perform efficient load balancing. Dhamija et al. [6] and Sachs [7] give detailed instructions on the deployment of OpenID system. However, Sun et al. [8] argue that because of the differences of the relying parties’ requirements, OpenID may not be user friendly as users need to type in their URLs. Some works argue that OpenID is vulnerable to phishing attack [9–11], a malicious relying party could redirect the user to a phishing website and obtain the user’s password. Many further researches have been conducted to address the phishing problem. Lee et al. [11] proposed a mechanism to prevent phishing attack by using token and email verification. Urien et al. [12] also gave a solution to the phishing problem on the basis of secure sockets layer smart cards.
3.2.1. OpenID. OpenID [5] is a decentralized single sign-on mechanism. It allows system to have multiple IDPs. Each OpenID user uses a unique URL as their identifier. When a user wants to access a service, he or she needs to prove his or her ownership of that URL before an SP accepts service request. By using OpenID, SPs are able to accept identities issued by other management domains, but it is limited to using OpenID only.
3.2.2. Shibboleth. Shibboleth [13] is a federated identity management system [14] (FIM) based on Security Assertion Markup Language (SAML) [15] protocol. The IDPs in this mechanism use SAML assertion to transmit their users’ identities to the SPs, which might be in another management domain. By using SAML protocol, shibboleth can be used in a federation established by a group of SPs and IDPs, which agrees to work together. SPs in this federation
Security Comm. Networks 2016; 9:2843–2860 © 2015 John Wiley & Sons, Ltd. DOI: 10.1002/sec
2845
Authentication web in cloud
are able to accept the SAML assertion provided by any IDPs in the same federation, which means that these SPs could perform cross-domain authentication inside their federation. As a SAML-based FIM system, shibboleth has to tackle man-in-the-middle attack. Three approaches, which could protect SAML-based FIM against man-in-themiddle attacks, have been proposed. (i) Binding the SAML assertion and the SAML artifact to the transport layer security (TLS) client’s certificate public key [16]; (ii) combining the security of TLS with the browser’s Same Origin Policy [17]; and (iii) binding the SAML assertion to the TLS session that has been agreed upon between client and relying party and as a result rely the user authentication [18]. 3.2.3. OAuth. OAuth (open authorization) [19] is an open protocol about authorization. Pai et al. [20] state that OAuth enables the user to authorize a web server to obtain the user’s resources on another server without obtaining the users’ password. Jorge et al. [21] describe the main process of OAuth in their work, which is shown in Figure 2. In the authorization process, the consumer could not obtain any information about the user’s privacy and password, which means that OAuth is able to perform secure cross-domain authentication.
G. Zhao et al.
However, most existing SSO systems have the problem of single point of failure. For example, Kormann [24] argues that protocols like passport have a core node, which could affect the security of the whole system, as the node will attract a large number of attacks. Oppliger et al. [25,26] also state that the importance of the authentication system’s core node might lead to single point of failure. Kakizaki et al. [27,28] proposed two solutions to tackle the single point of failure problem. (1) Redundancy of verification server. This method uses multiple servers to verify users’ identities. The system is available as long as there is still one server working. (2) Identity provider sends users single sign-on identities (SSOID) corresponding to different SSO servers. With all these SSOIDs, SPs could verify users’ identities successfully if at least one SSO server is online. This kind of solutions uses extra SSO servers to increase the availability of the system. Multiple SSO servers make the authentication service available when at least one SSO server is online. However, the cost of additional SSO servers makes these solutions much more expensive. 3.4. Formal analysis of authentication
3.3. Single point of failure in authentication system Single sign-on system enables users to access multiple services with one single identity. Therefore, the break down of this kind of system might make most services unaccessible. Josang et al. [22] and Goode et al. [23] argue that authentication system should provide great user experience and make sure that users are able to access the right services at the right time.
Figure 2. Authorization process in OAuth. SP, service provider.
2846
To investigate the security of an authentication protocol, formal analysis is always necessary. Extensive works have been performed on methods to analyze authentication architectures and authentication protocols. Butler et al. [29] give a clear summary of the authentication mechanism’s requirement. They argue that authentication mechanisms must be flexible and lightweight, allowing administrators to quickly establish and change resource-sharing arrangements. Sharing mechanisms cannot change local policies and must allow individual institutions to maintain control over their own resources. Burrows et al. [30] present a method to discover subtleties and errors in the protocols. It allows us to describe the beliefs of trustworthy parties involved in authentication protocols and the evolution of these beliefs as a consequence of communication. Lampson et al. [31] proposed a theory of authentication, which is based on the notation of principal and a ‘speaks for’ relation between principals. The theory shows how to reason about a principal’s authority by deducing the other principals that it can speak for. Bellare and Rogaway [32] also proposed a formal communication model for authentication in distributed environments. All of the preceding works have proposed their models in order to analyze the authentication mechanism formally. The logic is aiming at explaining the authentication protocols, and the theory and the model are both aiming at Security Comm. Networks 2016; 9:2843–2860 © 2015 John Wiley & Sons, Ltd. DOI: 10.1002/sec
G. Zhao et al.
Authentication web in cloud
Figure 3. Authentication architecture. IDP, identity provider; ASP, authentication service provider; SP, service provider.
explaining the authentication in the distributed environment. The mathematical model proposed in this work is aiming at analyzing the security issues in authentication architecture.
4. ARCHITECTURE AND FORMAL MODEL 4.1. Architecture As of traditional SSO systems, single point of failure and bottlenecks limit the security and the performance of the system. Both of these problems are caused by the essential of authentication system’s core node. If a conventional SSO system is applied to perform cross-domain authentication, the core node would likely become a bigger bottleneck for security and scalability, as well as availability. To address the preceding issues, this work applies two approaches to eliminate the core node: (1) Responsibility separation. The SSO server in traditional SSO system is responsible for identity management and identity verification. In this work, a SSO server is divided into IDPs and authentication SPs (ASPs). IDPs are responsible for Security Comm. Networks 2016; 9:2843–2860 © 2015 John Wiley & Sons, Ltd. DOI: 10.1002/sec
identity management, and ASPs are responsible for identity verification. (2) Large server clustering. Traditional SSO systems use one large SSO server to perform all authentication processes. In this work, multiple IDPs and ASPs are used to replace that large SSO server. With these two approaches, this work proposed a new authentication architecture to meet the authentication scenario in cloud environment. Figure 3 shows the new authentication architecture. There are four participants in the new authentication architecture: User: the end user of web service, who has to prove his or her identity to SPs before access resources. IDP: IDP is responsible for identity management. It issues user’s identity and helps ASP to verify those identities. ASP: ASP is responsible for identity verification. It helps SP to verify users’ identities. SP: SP provides services to user according to the ASP’s authentication result. In the new authentication architecture, the authentication process can be described in two steps: (i) a user logs in at the IDP of his or her management domain and 2847
G. Zhao et al.
Authentication web in cloud
obtains an identity credential issued by that IDP; and (ii) a user uses his or her identity credential to access SPs in other domains, and the SPs rely on the ASPs of their management domain to verify the user’s identity. The relationship between the four participants can be described in the following two domains: User management domains: A user management domain is the domain responsible for managing a group of users’ identities. Each IDP can belong to one user management domain only, whereas a user can belong to multiple user management domains. Service management domains: On behalf of a set of services, a service management domain is responsible for the authentications of users that are attempting to access the services. A service could belong to multiple service management domains. 4.2. Formal model 4.2.1. Mathematical model: digraph. The proposed architecture can be modeled using digraph. By using notations in Table I, the vertex set can be defined as four subsets of vertex as follows:
User vertex set: V(User) = {VUn |0 n a} IDP vertex set: V(IDP) = {VIn |0 n b} ASP vertex set: V(ASP) = {VAn |0 n c} SP vertex set: V(SP) = {VSn |0 n d}
where a, b, c and d are the numbers of users, IDPs, ASPs and SPs. Let V() be defined as follows: V() = V(User) [ V(IDP) [ V(ASP) [ V(SP) According to the participants’ relationship in the architecture, let E() represent the vertex set of the graph, the edge set can be described as follows:
Figure 4. G() = (V(), E()). IDP, identity provider; ASP, authentication service provider; SP, service provider.
f (Va , Vb ) > 0 represents that this digraph contains at least one edge formed by Va and Vb . Let G() (Figure 4) be the graph that represents an authentication web G() = (V(), E()) 4.2.2. Definition of authentication. In the architecture, a specific authentication process is performed by four specific participants, the corresponding authentication in the graph would be the following directed path: DP(Vuseri , VIDPj , VASPm , VSPn ) = (Vuseri ! e(Vuseri !VIDPj ) ! VIDPj ! e(VIDPj !VASPm ) ! VASPm ! e(VASPm !VSPn ) ! VSPn )
E(U – I) = {(Va , Vb )|(Va 2 V(User), Vb 2 V(IDP)), f (Va , Vb ) > 0} E(I – A) = {(Va , Vb )|(Va 2 V(IDP), Vb 2 V(ASP)), f (Va , Vb ) > 0} E(A – S) = {(Va , Vb )|(Va 2 V(ASP), Vb 2 V(SP)), f (Va , Vb ) > 0} E() = E(U – I) [ E(I – A) [ E(A – S)
If [Va , Vb ] represents the set of the directed path from Va to Vb in G(), the necessary and sufficient condition for vertexes Va and Vb to perform an authentication process would be |[Va , Vb ] | 1. [Va , Vb ] = {DP(V1 : : : Vi , Vi+1 : : : Vn )|V1 = Va , Vn = Vb , Vi 2 V()(1 i n), e(Vi !Vi+1 ) 2 E()(1 i n – 1)}
Table I. Notations. Symbol Vi eVa !Vb
2848
Description Participant I’s corresponding vertex in the digraph A directed edge from Va to Vb The digraph abstracted from the architecture
4.2.3. Single sign-on. With the proposed architecture, if an IDP is trusted by multiple ASPs, meaning that users of the IDP can authenticate himself or herself to the IDP and then his or her identity can be accepted by the ASPs and access services of the ASPs multiple times without authenticating himself or herself again. Security Comm. Networks 2016; 9:2843–2860 © 2015 John Wiley & Sons, Ltd. DOI: 10.1002/sec
G. Zhao et al.
Authentication web in cloud
{Vuseri , Vspj } 2 A(G()) represents the possible authentication process in G(). By eliminating Vi from G(), the new graph G()0 could not perform any possible authentication process belonging to G(). Therefore, Vi is a single point of failure. Partial failure (G()):
This can be formalized as in the succeeding text. For
8Va 2 V(ASP)
If
Vi 2 {V1 |(V1 2 V(IDP), f (V1 , Va ) 1} Vu 2 {V1 |(V1 2 V(User), f (V1 , Vi ) 1} Vs 2 {V1 |(V1 2 V(SP), f (V1 , Va ) 1}
then
|[Vu , Vs ] | 1.
9Vi 2 V(), 9{Vuseri , Vspj } 2 A(G()), {Vuseri , Vspj } … A(G(0 ))
According to the definition of authentication, |[Vu , Vs ] | 1 represents that Vs can authenticate Vu successfully. The equation means that if G() contains at least one edge formed by Vi and Va , each Vs connected with Va can authenticate all Vu connected with Vi .
{Vuseri , Vspj } 2 A(G()) represents the possible authentication process in G(). By eliminating Vi from G(), some possible authentication processes belonging to G() is unable to perform in the new graph G()0 . Therefore, Vi is a partial failure.
4.2.4. Single point of failure and partial failure. Single point of failure: One of the system’s participants’ off-line would make all the possible authentication processes fail to perform. Partial failure: One of the system’s participants’ off-line would make some of the possible authentication processes fail to perform. By using notations in Table II, the aforementioned definitions can be denoted as follows: Single point of failure (G()):
5. SECURITY ANALYSIS 5.1. Vertex failure In the authentication architecture, some important problems lead by the vertex failure are single point of failure and partial failure. Both of these two failures are analyzed on the basis of the proposed mathematical models.
9Vi 2 V(), 8{Vuseri , Vspj } 2 A(G()), {Vuseri , Vspj } … A(G(0 ))
Table II. Notations in single point of failure and partial failure. Symbol Vi 0
A(G()) A(G(0 ))
Description One of the vertexes in G(), Vi 2 V() The new graph without Vi , G(0 ) = (V(0 ), E(0 )), V(0 ) = V() – Vi , E(0 ) = E() – {(Va , Vb )|Va = Vi [ Vb = Vi , (Va , Vb ) 2 E()} The possible authentication process set in G() A(G()) = {{Vui , Vspj }|Vui 2 V(user), Vspj 2 V(SP), |[Vui , Vspj ] | > 0} The possible authentication process set in G(0 ) A(G(0 )) = {{Vui , Vspj }|Vui 2 V(user0 ), Vspj 2 V(SP0 ), |[Vui , Vspj ]0 | > 0}
Table III. Assumptions. Assumption No isolated user No isolated IDP No isolated ASP No isolated SP Multiple entities in each vertex set
Description 9Va 2 V(User), SP(Va ) = {VSPi |VSPi 2 V(SP), |[Va , VSPi ]| > 0} ¤ 2.1: 9Va 2 V(IDP), SP(Va ) = {VSPi |VSPi 2 V(SP), |[Va , VSPi ]| > 0} ¤ 2.2: 9Va 2 V(IDP), User(Va ) = {VUseri |VUseri 2 V(User), |[VUseri , Va ]| > 0} ¤ 3.1: 9Va 2 V(ASP), SP(Va ) = {VSPi |VSPi 2 V(SP), |[Va , VSPi ]| > 0} ¤ 3.2: 9Va 2 V(ASP), User(Va ) = {VUseri |VUseri 2 V(User), |[VUseri , Va ]| > 0} ¤ 9Va 2 V(SP), User(Va ) = {VUseri |VUseri 2 V(User), |[VUseri , Va ]| > 0} ¤ 5.1: |V(User)| > 1 5.2: |V(IDP)| > 1 5.3: |V(ASP)| > 1 5.4: |V(SP)| > 1
IDP, identity provider; ASP, authentication service provider; SP, service provider.
Security Comm. Networks 2016; 9:2843–2860 © 2015 John Wiley & Sons, Ltd. DOI: 10.1002/sec
2849
G. Zhao et al.
Authentication web in cloud
5.1.1. Assumptions. The assumptions of the vertex failure’s analysis are described in Table III.
Vi 2 V(IDP) [ V(ASP), B(Vi ) can be represented as follows: B(Vi ) = {{VUa , VSPj }||[VUa , VSPj ]| – |[Vi , VSPj ]|
5.1.2. Analysis on single point of failure. On the basis of the single point of failure’s definition in this work, if Vi is a single point of failure vertex, A(G()) ¤ , A(G(0 )) = . On the basis of the partial failure’s definition in this work, if Vi is a partial failure vertex, A(G(0 )) ¤ , B(Vi ) = A(G()) – A(G(0 )) ¤ . Because IDP and ASP are not end vertexes, both of them might be single point of failure vertexes and assume
= 0, |[VUa , VSPj ]| ¤ 0, |[Vi , VSPj ]| ¤ 0, VSPj 2 V(SP), VUa 2 User(Vi )}
5.1.2.1. Identity provider vertex. Identity provider vertex is not an end vertex, it controls the communication channel between user and ASP, which means that its failure
Figure 7. Analysis of single point of failure (authentication service provider (ASP)). Figure 5. Analysis of single point of failure (identity provider).
Figure 6. Analysis of partial failure (identity provider).
2850
Figure 8. Analysis of partial failure (authentication service provider (ASP)). SP, service provider.
Security Comm. Networks 2016; 9:2843–2860 © 2015 John Wiley & Sons, Ltd. DOI: 10.1002/sec
G. Zhao et al.
Authentication web in cloud
might cut off the communication channel between user and ASP. But with the preceding assumptions, it can be proved that 8Vi 2 V(IDP), A(G(0 )) = A(G()) – B(Vi ) ¤ , which means that IDP is not a single point of failure vertex. The proof is shown in Figure 5. Although Figure 5 proves that IDP is not a single point of failure vertex, it still might be a partial failure vertex. However, Figure 6 proves that this kind of failure is avoidable.
Figure 9. Example of G(). IDP, identity provider; ASP, authentication service provider; SP, service provider.
5.1.2.2. Authentication service provider vertex. Identity provider vertex is also not an end vertex. It controls the communication channel between IDP and SP, which means that its failure might cut off the communication channel between them. But with the preceding assumptions, it can also be proved that 8Vi 2 V(ASP), A(G(0 )) = A(G())–B(Vi ) ¤ , which means that ASP is not a single point of failure vertex. The proof is shown in Figure 7. Although Figure 7 proves that IDP is not a single point of failure vertex, it still might be a partial failure vertex. However, Figure 8 can also prove that this kind of failure is avoidable. 5.1.3. Detecting partial failure. Because partial failure could be avoidable, the detection of critical vertex could contribute directly to the avoidance of partial failures. In the graph, this kind of vertex is called cut vertex. In the architecture, different users use different IDPs to hold their identity, which means that for one single user(Vuseri ), the digraph related to him or her is only a subgraph of G() (Figure 9), if using G(useri ) (Figure 10) to represent the subgraph, the definition of G(useri ) can be described as follows: V(useri ) = {Vi |N[Vuseri , Vi ] > 0 [ Vi = Vuseri } E(useri ) = {(V1 , V2 )|V1 2 V(useri ), V2 2
Figure 10. Example of G(useri ). IDP, identity provider; ASP, authentication service provider; SP, service provider.
V(useri ), (V1 , V2 ) 2 E()} G(useri ) = (V(useri ), E(useri ))
Table IV. Notations in cut vertex detection algorithm. Symbol Forward subvertex Reverse subvertex Forward depth first search (FDFS) Reverse depth first search DD(Vi )
Visited(Vi )
SS(Vi ) FSS(Vi ) Rss(Vi )
Description If Vi is a forward subvertex and Vj is its parent vertex, there exists a directed edge from Vj to Vi If Vi is a reverse subvertex and Vj is its parent vertex, there exists a directed edge from Vi to Vj DFS used by forward subvertex DFS used by reverse subvertex DD means dangerous degree, it is a parameter of vertex, DD(Vi ) is represented by Vi ’s DD. If a subvertex’s DD is bigger than its parent vertex’s DD, that parent vertex is a cut vertex. Visited (Vi ) is used to represent whether Vi has performed FDFS or not. Visited(Vi ) = true means Vi has performed FDFS already, visited(Vi ) = false means Vi has not performed FDFS yet Vi ’s subvertex set Vi ’s forward subvertex set Vi ’s reverse subvertex set
Security Comm. Networks 2016; 9:2843–2860 © 2015 John Wiley & Sons, Ltd. DOI: 10.1002/sec
2851
G. Zhao et al.
Authentication web in cloud
In order to help the user to find out the cut vertexes in his or her authentication graph, an algorithm has been made to search the cut vertexes. Table IV explains the notations used to clarify the algorithm.
5.1.3.1. Forward depth first search. If forward depth first search (FDFS) is performed on vertex Vi, it has five steps (1) Initialization: if Vi 2 V(User), DD(Vi ) = 1, else, DD(Vi ) = DD(Vi–1 ) + 1 ,Vi–1 is Vi ’s parent vertex. Visited(Vi ) = true. (2) Obtain Vi ’s subvertex set SS(Vi ). (3) 8Va 2 SS(Vi ), if Visited(Va ) = false and Va is Vi ’s forward subvertex, perform FDFS on Va and record DD(Va ). If Visited(Va ) = false and Va is Vi ’s reverse subvertex, perform reverse depth first search (RDFS) on Va and record DD(Va ). If Visited(Va ) = true, DD(Va ) has been calculated before, record it. (4) If Vi Max({DD(Vn )|Vn 2 FSS(Vi )}), Vi is a cut vertex, record it. (5) If |RSS(Vi )| > 0, DD(Vi ) = Min({DD(Vn )|Vn 2 RSS(Vi )}), If |RSS(Vi )| = 0, DD(Vi ) = Max({DD(Vn )|Vn 2 FSS(Vi )}).
5.1.3.2. Reverse depth first search. If RDFS is performed on vertex Vi , it has four steps 1. Initialization: DD(Vi ) = DD(Vi–1 ) + 1 ,Vi–1 is Vi ’s parent vertex. 2. Obtain Vi ’s reverse subvertex set RSS(Vi ). 3. 8Va 2 RSS(Vi ), if Visited(Va ) = false and Va is Vi ’s reverse subvertex, perform RDFS on Va and record DD(Va ). If Visited(Va ) = true, DD(Va ) has been calculated before, record it. 4. If |RSS(Vi )| > 0, DD(Vi ) = Min({DD(Vn )|Vn 2 RSS(Vi )}).
5.1.3.3. Searching process. The search process is performed on G(useri ), and there is only one user vertex in G(useri ). This algorithm uses Vuseri as the root vertex and performs FDFS on it; after this process, all the cut vertexes are recorded. 5.2. Privacy protection The protection of the user’s privacy is one of the authentication system’s major concerns. In the new architecture, the user’s privacy is protected by the user privacy gateway, which is used to control the user privacy flow. The user privacy flow is shown in Figure 11. The main feature in Figure 11 can be described as follows: (1) IDP plays the role of cross-domain user privacy gateway: Figure 11 shows that IDP controls all the user privacy obtained from its user. Because IDP is the only holder of the user’s privacy, it would be able to control the flow of user privacy from user to 2852
ASP, so the flow of user privacy between different management domains is under the IDP’s control. (2) ASP plays the role of intradomain user privacy gateway: Figure 11 shows that SP can obtain user privacy from ASP. Because ASP and SP are in the same management domain, ASP would be able to control the user privacy obtained by SP, although ASP is not the only holder of the user’s privacy. (3) Decrease the IDP’s workload on user privacy control: IDP in this architecture only needs to control the ASP’s access to the user privacy, and the SP’s access to the user privacy is controlled by ASP.
6. DECENTRALIZED VERIFICATION MECHANISM 6.1. Mechanism design In order to solve the single-point issue, the architecture proposed in this work divided SSO server into IDPs and ASPs. According to the description of the architecture, IDP is only responsible for identity management (identity issuance), and ASP is only responsible for identity verification. So, IDP should not be involved in the identity verification process, which means that the identity verifier should be able to verify the users’ identities without the involvement of identity issuer. This work proposed a decentralized verification mechanism to cover the preceding issue. In this mechanism, ASPs are able to authenticate other domain’s users without the involvement of that domain’s IDP, and the user could also verify the ASP’s identity during the same authentication process. This decentralized verification mechanism uses two kinds of token to achieve decentralized authentication. The first kind of token is called UToken, it is generated by IDP, and user could use it to prove his or her identity to any ASP without revealing his or her UToken. The second kind of token is called AToken, it is also generated by IDP, and ASP could use it to verify any UToken issued by that IDP without revealing its AToken to any individuals. To cover the aforementioned requirements, UToken and AToken are generated by a special kind of algorithm called Token Generation Algorithm (TGA). TGA is not a specific algorithm; it could be any algorithm with the following features (‡ represents for TGA): (1) Parameter necessity: A‡B is the result of the algorithm with the inputs of A and B. In the process of computing A‡B, both A and B are necessary. (2) Irreversibility: It is impossible to use A‡B and A to generate B, and using A‡B and B is also impossible to generate A. (3) Commutativity from the second parameter: If TGA has more than two parameters, the computation sequence after the first parameter should have no Security Comm. Networks 2016; 9:2843–2860 © 2015 John Wiley & Sons, Ltd. DOI: 10.1002/sec
G. Zhao et al.
Authentication web in cloud
Figure 11. User privacy data flow. IDP, identity provider; ASP, authentication service provider; SP, service provider.
6.2. Security analysis
Figure 12. Decentralized verification process. IDP, identity provider; ASP, authentication service provider.
effect on the result, which means that X‡A‡B‡C = X‡A‡C‡B = X‡B‡A‡C = X‡B‡C‡A = X‡C‡B‡A = X‡C‡A‡B. With the preceding features, TGA could be used to generate UToken and AToken. In the design of the tokens, KeyIDP is a private key hold by IDP, KeyUser is a public key that belongs to the User and KeyASP is a public key that belongs to ASP. UToken: Public part: KeyUser Private part: KeyIDP KeyUser AToken: Public part: KeyASP Private part: KeyIDP KeyASP The verification process between User and ASP is shown in Figure 12. Firstly, ASP sends the public part (KeyASP ) of AToken to user, and user uses the private part of UToken to generate a temporary key (KeyIDP KeyUser KeyASP ); secondly, user sends the public part (KeyUser ) of his or her UToken to ASP, and ASP uses the private part of AToken (KeyIDP KeyASP ) to generate the temporary key (KeyIDP KeyASP KeyUser ). Because of the third feature of TGA, KeyIDP KeyUser KeyASP = KeyIDP KeyASP KeyUser , so User and ASP could authenticate each other by verifying this temporary key. The verification process shows that User and ASP could use their tokens to authenticate each other without the involvement of IDP. Security Comm. Networks 2016; 9:2843–2860 © 2015 John Wiley & Sons, Ltd. DOI: 10.1002/sec
Decentralized verification mechanism enables users to access different domains with the same token. All token verification processes are performed without the participation of the user domain manager (IDP). Although this kind of verification mechanism could sharply reduce IDP’s burden, it also brings two new security issues (1) Authentication deceive: Without the involvement of IDP, SPs from other domains could easily forge the result of the authentication. (2) Identity stealing: Because a user’s token is able to access different domains, if an SP obtains the user’s token through the authentication process, the SP could easily steal the user’s identity in other domains. In this work, the proposed decentralized verification mechanism enables user and ASP to use their tokens to authenticate each other without the involvement of IDP. Because of the features of TGA, other individuals are not able to obtain or calculate the private part of their tokens. The information each individual could obtain or calculate during the verification process is shown in Table V (assume that user and ASP use challenge response to verify temporary key). With the information in Table V, the proposed mechanism shows two important features (1) Mutual authentication: The information in Table V shows that, in the authentication process, user and ASP have equal status, the authentication process is not a success unless both the user and ASP could authenticate each other successfully. (2) Asymmetrical token: TGA-based token have two different parts. Attacker could not steal user’s identity, unless he or she could obtain the private part of user’s token. Table V shows that, in the authentication process, only the public part is transmitted to the authenticator, and the private part is limited in the user’s device. 2853
G. Zhao et al.
Authentication web in cloud
Table V. Information each individual could obtain or calculate during the verification process. Individual User
IDP ASP
SP
Information KeyASP ENC(KeyIDP KeyUser KeyASP , ASPChallenge) ENC(KeyIDP KeyASP KeyUser , ASPResponse) KeyIDP KeyUser KeyASP (Calculated) KeyUser ENC(KeyIDP KeyASP KeyUser , UserChallenge) ENC(KeyIDP KeyUser KeyASP , UserResponse) KeyIDP KeyASP KeyUser (Calculated) KeyASP , KeyUser ENC(KeyIDP KeyUser KeyASP , ASPChallenge) ENC(KeyIDP KeyASP KeyUser , ASPResponse) ENC(KeyIDP KeyASP KeyUser , UserChallenge) ENC(KeyIDP KeyUser KeyASP , UserResponse)
IDP, identity provider; ASP, authentication service provider; SP, service provider.
However, identity unification is a very dangerous operation. It requires a very strong trust relationship between user and all the involved IDPs. If any of the involved IDPs are not trustable, the identity unification operation might hurt the user’s interest. For example, Figure 13 shows the situation that Bob unifies two identities. The first identity is issued by PayPal, and the second identity is issued by an Internet forum. The identity unification operation enables the Internet forum to use the user’s identity to access his PayPal account, which might hurt the user’s interest. It is obvious that a secure and available identity unification mechanism of a cross-domain authentication system should meet the following two requirements. (1) User should be able to use a single identity to obtain all the resources that belong to him or her even if those resources are corresponding to other identities. (2) User should be able to protect his or her own resources. Other individuals should not be able to access the user’s resources even if they have any of his or her identity. In this work, our identity unification mechanism introduced a factor called identity unification factor (IUF) to meet the preceding requirements. IUF is a specific factor included in the users’ authentication message. The authentication message from the same user would have the same IUF even when the user is using different identities. In this way, after the user’s identity is authenticated successfully,
Figure 13. Dangerous identity unification operation. IDP, identity provider; SP, service provider.
With the aforementioned features, it is obvious that the decentralized verification mechanism proposed in this work could cover the security issues mentioned earlier.
7. IDENTITY UNIFICATION MECHANISM Most of the users already have a lot of identities from various management domains. Because different identities always correspond to different resources, users would not like to abandon any of their identities. Therefore, SSO system should be able to unify the users’ existing identities. 2854
Figure 14. User proves his or her ownership of identity unification factor to service provider. ASP, authentication service provider.
Security Comm. Networks 2016; 9:2843–2860 © 2015 John Wiley & Sons, Ltd. DOI: 10.1002/sec
G. Zhao et al.
SP could unify the present identity with other identities corresponding to the same IUF. In order to meet the preceding requirements, IUF should also have the following features: (1) Identity unification factor should be provided by the user. Because the same user would use the same IUF at different IDPs, the user should manage his or her own IUF and provide it to all the IDPs, which would involve in the identity unification process. (2) User should be able to prove his or her ownership of his or her IUF. To protect the user’s resource, after the user’s identity is authenticated, SP would also verify the user’s ownership of his or her IUF. In this way, no IDPs would be able to access the user’s resources without the user’s permission. In the decentralized verification mechanism, the user’s UToken includes a public part (KeyUser ) and a private part (KeyIDP KeyUser ). It is obvious that the public part can be provided by user, and therefore, it can be used as IUF. To give the user a method to prove his or her ownership of his or her IUF, a method called TGKey is designed on the basis of TGA. TGKey is a pair of keys that user could use the private key to prove his or her ownership of the public key, and therefore, the public key of TGKey can be used as the user’s IUF. The design of TGKey is as follows: Private key KeyU: KeyU is a private key held by the user, it is produced by the user and would not be revealed to any individuals. Public key KeyU‡A: Both KeyU‡A and A are public keys, it is produced by the user and could be transmitted to any individuals.
Authentication web in cloud
By using KeyU‡A as IUF, when the SP asks the user to prove his or her ownership of KeyU‡A, it would send a challenge B to the user, then the user would use KeyU to calculate KeyU‡B and send it back to the SP. Because KeyU‡A and A are public keys, SP can use KeyU‡A and B to calculate KeyU‡A‡B and use KeyU‡B and A to calculate KeyU‡B‡A. If KeyU‡A‡B and KeyU‡B‡A are equal, it means that KeyU‡B is right, and the user has the right KeyU, which means that the user is the owner of that IUF. Figure 14 shows the aforementioned process. With the preceding design, the combination of cross-domain authentication process and identity unification process can be described as follows (Figure 15): (1) User logs in at IDP and sends his or her IUF to IDP. (2) IDP uses the user’s IUF to generate a UToken and sends it to the user. (3) User applies for the resources in an SP. (4) The SP sends challenge B to the user and asks the user to send the authentication message and prove his or her ownership of the IUF contained in that message. (5) The user sends SP the authentication message and the response for challenge B. (6) SP sends the user’s authentication message to its ASP. (7) ASP sends SP the authentication result. (8) SP verifies the user’s ownership of the IUF. (9) SP finds out all the identities with the same IUF and sends the user all the corresponding resources.
Figure 15. Combination of cross-domain authentication and identity unification. IUF, identity unification factor; IDP, identity provider; ASP, authentication service provider; SP, service provider.
Security Comm. Networks 2016; 9:2843–2860 © 2015 John Wiley & Sons, Ltd. DOI: 10.1002/sec
2855
G. Zhao et al.
Authentication web in cloud
Table VI. Notation used in authentication protocol. Notation ENC(X,Y) PUBENC(X,Y) PRIENC(X,Y) HMAC(X,Y) X||Y
Description Use X as a key to encrypt Y Use X as a public key to encrypt Y Use X as a private key to encrypt Y Use X as a key to calculate the hash-based message authentication code of Y Hyphenation Figure 16. UToken obtaining process. IDP, identity provider.
8. AUTHENTICATION PROCESS AND PROTOCOL IMPLEMENTATION The authentication protocol in this work is on the basis of the decentralized verification mechanism. With the description in Section 6, the authentication process of the decentralized verification mechanism can be divided into three subprocesses UToken obtaining process: IDP authenticates the user and sends UToken to that user. AToken obtaining process: IDP authenticates the ASP and sends AToken to that ASP. Cross-domain authentication process: User and ASP use their tokens to authenticate each other. Correspondingly, the authentication protocol uses three subprotocols to perform the preceding processes. To clarify these authentication protocols clearly, the notations in Table VI are used to describe the protocols. 8.1. UToken obtaining protocol The first step of cross-domain authentication is user authentication process. Its responsibility includes authenticating user’s identity and sending UToken to the legal user. Because the authentication process in this part is intradomain authentication, most authentication protocols can be used to authenticate the user’s identity. IDP could use its own protocol to perform intradomain authentication, and the proposed protocol is only responsible for the additional cross-domain authentication process. In this work, a simple authentication protocol called UToken obtaining protocol (UOP) is used to perform intradomain authentication process. Figure 16 shows the process of this protocol. UOP1 User ! IDP: user sends intradomain authentication message to IDP and uses this secure channel to send a temporary key (RKey), which is used to encrypt UToken. UOP Protocol: Intradomain authentication Message, ENC(ChannelKey, Rkey) UOP2 IDP ! User: IDP uses Rkey to form a secure channel to send UToken to the User. 2856
Figure 17. AToken obtaining process. IDP, identity provider; ASP, authentication service provider.
UOP Protocol: Index, AIndex, ENC(RKey, PubKeyI|| KeyI‡Index||KeyI‡AIndex) HMAC(RKey,Index||AIndex||ENC(RKey,PubKeyI|| KeyI‡Index||KeyI‡AIndex)) Description: Index: the public part of UToken, it contains IUF. AIndex: the public part of Anonymous UToken, it does not contain IUF. PubKeyI: IDP’s public key, it can be used to verify IDP’s identity. KeyI: IDP’s key, it is used to form UToken and AToken.
8.2. AToken obtaining protocol In the AToken obtaining process, IDP authenticates ASP’s identity and sends AToken to the legal ASP; ASP stored the AToken after authenticating the IDP successfully. Because AToken will be used in the following decentralized crossdomain authentication process. ASP should be able to prove its ownership of that AToken without the participation of IDP. In AToken obtaining protocol (AOP), ASP’s identity is a public key, which is also the public part of its AToken. As the only holder of the corresponding private key, only ASP could prove its ownership of that AToken. IDP’s identity is also a public key. After authenticating IDP’s ownership of that public key, ASP uses that public key to represent the issuer of the corresponding AToken. Figure 17 shows the process of this protocol. Security Comm. Networks 2016; 9:2843–2860 © 2015 John Wiley & Sons, Ltd. DOI: 10.1002/sec
G. Zhao et al.
AOP1 ASP ! IDP: ASP sends its public key and proves the ownership of that public key. AOP Protocol: KeyA, TimeStamp, Challenge, PRIENC(PriKeyA, TimeStamp||Challenge) Description: KeyA: ASP’s public key, which is also the public part of AToken. PriKeyA: ASP’s private key. TimeStamp: the time when this message was generated. AOP2 IDP ! ASP: IDP proves its ownership of a public key and sends AToken to ASP. AOP Protocol: PUBENC(KeyA, KeyIKeyA), PRIENC(PriKeyI, PUBENC(KeyA, KeyIKeyA)||Challenge) Description: PriKeyI: IDP’s private key. 8.3. Cross-domain authentication protocol Considering the user’s demand for anonymous crossdomain authentication, the cross-domain authentication protocol consists of two different protocols to meet the user’s requirement. 8.3.1. Anonymous cross-domain authentication protocol. Anonymous cross-domain authentication protocol (ACAP) is used to authenticate the user’s identity, which is issued by other management domain’s IDP. SPs can use this protocol to verify whether a user has log in at an IDP. Figure 18 shows the process of this protocol. ACAP1 User ! SP: User requests for SP’s service. ACAP Protocol: Service request.
Authentication web in cloud
ACAP2 SP ! User: SP sends user the public part of ASP’s AToken and requests the user to send authentication message. ACAP Protocol: Authentication request, KeyA. ACAP3 User ! SP: User sends a challenge and authentication message to SP. The challenge is used to authenticate the SP’s identity. The authentication message is generated by KeyA and contains the response to the challenge. ACAP Protocol: AIndex, PubKeyI, IDPIP, TimeStamp, ENC(Key1, KeyU-S), ENC(KeyIAIndexKeyA, Key1), HMAC(KeyIAIndexKeyA, Key1||TimeStamp), HMAC(Key1, KeyU-S). Description: ENC (Key1, KeyU-S): the challenge. KeyU-S: the response to the challenge. SP would obtain the response only if ASP could decrypt Key1 successfully. TimeStamp: the time when this message was generated. ACAP4 SP ! ASP: SP proves its identity to ASP and sends the user’s authentication message to ASP. ACAP Protocol: AIndex, PubKeyI, IDPIP, TimeStamp, SPID PRIENC(PriKeyS, AIndex ||PubKeyI||TimeStamp) ENC(KeyIAIndexKeyA, Key1) HMAC(KeyIAIndexKeyA, Key1||TimeStamp) Description: PriKeys: SP’s private key. ACAP5 ASP ! SP: ASP proves its identity to SP and sends SP the response of the challenge. ACAP Protocol: PUBENC(PubKeyS, Key1),
Figure 18. Anonymous cross-domain authentication process. ASP, authentication service provider; SP, service provider.
Security Comm. Networks 2016; 9:2843–2860 © 2015 John Wiley & Sons, Ltd. DOI: 10.1002/sec
2857
G. Zhao et al.
Authentication web in cloud
PRIENC(PriKeyA, PUBENC(PubKeyS, Key1)) ACAP6 SP ! User: SP sends success message to the User and uses KeyU-S to prove its identity. ACAP Protocol: Success message, ENC (KeyU-S, Sessionkey), HMAC(KeyU-S, Sessionkey) Description: Sessionkey: the key SP used to provide services to the user. Anonymous cross-domain authentication protocol enables users and ASPs to authenticate each other in an anonymous way. In the authentication process, the following information are verified. (1) User’s management domain: verifying UToken (2) SP’s management domain: verifying AToken By verifying the aforementioned information, SPs and users could locate each other’s management domain. Without verifying the detail of the user’s identity, the crossdomain privacy leakage is greatly reduced. 8.3.2. Nonanonymous cross-domain authentication protocol. Nonanonymous cross-domain authentication protocol (NCAP) is used to authenticate the user’s identity, which is issued by other management domain’s IDP. SPs can use this protocol to verify the user’s identity and his or her ownership of UIF and then unify all the identities belonging to this user. Figure 19 shows the process of this protocol. NCAP1 User ! SP: User requests for SP’s service. NCAP Protocol: Service request. NCAP2 SP ! User: SP sends user the public part of ASP’s AToken and a challenge for the user’s ownership of IUF and request the user to send authentication message.
NCAP Protocol: Authentication request, KeyA, E. NCAP3 User ! SP: User sends a challenge, a response and authentication message to SP. The challenge is used to authenticate the SP’s identity. The response is used to prove his or her ownership of the IUF. The authentication message is generated by KeyA and contains the response to the challenge. NCAP Protocol: A, Index, PubKeyI, IDPIP, TimeStamp, ENC(Key1, KeyU-S||KeyUE), ENC(KeyIIndexKeyA, Key1) HMAC(KeyIIndexKeyA, Key1||TimeStamp) HMAC(Key1, KeyU-S||KeyUE). Description: A: a public key of user’s TGKey, another public key is IUF, it is contained in Index. KeyU: the private key of user’s TGKey. NCAP4 SP ! ASP: SP proves its identity to ASP and sends the user’s authentication message to ASP. NCAP Protocol: Index, PubKeyI, IDPIP, TimeStamp, SPID PRIENC(PriKeyS, Index||PubKeyI||TimeStamp) ENC(KeyIIndexKeyA, Key1) HMAC(KeyIIndexKeyA, Key1||TimeStamp) NCAP5 ASP ! SP: ASP proves its identity to SP and sends SP the response of the challenge. ASP also uses its private key to issue the corresponding relationship between the SP’s public key and the information of its service. NCAP Protocol: PUBENC(PubKeyS, Key1), PRIENC(PriKeyA, PUBENC(PubKeyS, Key1)) PRIENC(PriKeyA, PubKeyS||ServiceInformation) Description: PRIENC(PriKeyA,
Figure 19. Nonanonymous cross-domain authentication process. ASP, authentication service provider; SP, service provider; IUF, identity unification factor.
2858
Security Comm. Networks 2016; 9:2843–2860 © 2015 John Wiley & Sons, Ltd. DOI: 10.1002/sec
G. Zhao et al.
PubKeyS||ServiceInformation): used to inform the user the information of the SP and therefore prevent phishing attack. NCAP6 SP ! User: (i) SP sends success message to the user and uses KeyU-S to prove its identity; (ii) SP sends the corresponding relationship between its public key and the information of its service; and (iii) SP proves his or her ownership of his or her public key. NCAP Protocol: Success message, PubKeyS, ENC(KeyU-S, Sessionkey), PRIENC(PriKeyS, ENC(KeyU-S, Sessionkey)), PRIENC(PriKeyA, PubKeyS||ServiceInformation)
Authentication web in cloud
different management domains; and (iii) SPs are able to gain the support for hybrid authentication protocols with minimal cost. Secondly, we develop a formal mathematical model to analyze the security issues of the proposed architecture and proposed an algorithm to detect the authentication architecture’s weak vertex whose failure would lead to a partial failure in the architecture. With the help of this algorithm, the partial failure in the proposed architecture becomes avoidable. Thirdly, we proposed a secure cross-domain SSO protocol that covers the following requirement: (i) decentralized identity verification (eliminate single point of failure); (ii) secure identity unification; and (iii) cross-domain SSO.
ACKNOWLEDGEMENTS Nonanonymous cross-domain authentication protocol enables users and ASPs to authenticate each other in a nonanonymous way. In the authentication process, the following information are verified. (1) (2) (3) (4)
User’s management domain: Verifying UToken User’s identity: Verifying TGKey SP’s management domain: Verifying AToken SP’s service: Verifying ASP’s statement about the correspondence between SP’s public key and its service.
By verifying the preceding information, SPs could locate the user’s domain and unify the user’s identity of different management domains. Users could locate the SP’s domain and ensure the service of that SP.
9. CONCLUSION In this work, we investigated the scenario of SSO in cloud environments; the investigation shows that most existing SSO mechanisms fail to adapt to the cloud environment at least in four aspects. Firstly, most SSO mechanisms assume that SPs and SSO servers are under the same management domain. Secondly, some SSO mechanisms rely exclusively on one single SSO server to verify credentials, resulting in a bottleneck in performance and single point of failure. Thirdly, most SSO mechanisms are bound to only one specific authentication protocol. Fourthly, most SSO mechanisms have no identity unification mechanism. This work investigated a way to build authentication systems that allow cross-domain SSO and distributed identity management. The main contributions are as follows: Firstly, we propose a cross-domain SSO architecture that supports the following features: (i) SPs are able to accept user identities issued by many different IDPs from different management domains; (ii) user identities issued by IDP are able to be accepted by many different SPs from Security Comm. Networks 2016; 9:2843–2860 © 2015 John Wiley & Sons, Ltd. DOI: 10.1002/sec
This research is supported in part by the Guangzhou Research Infrastructure Development Fund (No. 2012224-12), the Guangdong Nature Science Fund (No. S2012030006242), the Guangzhou Zhujiang Future Fellow Fund (No. 2011J2200089), the China MOE Doctoral Research Fund (No. 20134407120017), the MOE-China Mobile Research Fund (No. MCM20121051), the China Nature Science Fund (No. 61370229), the MOEChina Mobile Joint Research Grant (No. MCM20130651) and the innovative R&D team program of Guangdong Province(NO.201001D0104726115).
REFERENCES 1. Pashalidis A, Mitchell C. A Taxonomy of Single SignOn Systems. Proceedings of the 8th Australasian Conference on Information Security and Privacy (ACISP), Wollongong, Australia, 2003; 249–264. 2. Pfitzmann B, Waidner M. Analysis of liberty singlesign-on with enabled clients. IEEE Internet Computing 2003; 7(6): 38–44. 3. Armando A, Carbone R, Compagna L, Cuellar J, Tobarra M. Formal analysis of SAML 2.0 web browser single sign-on: Breaking the SAML-based single signon for google apps. 6th ACM Workshop on Formal Methods in Security Engineering (FMSE 2008), Hilton Alexandria Mark Center, Virginia, USA, 2008; 1–10. 4. De Clercq J. Single sign-on architectures. In Infrastructure Security. Springer: Berlin/Heidelberg, 2002; 40–58. 5. Recordon D, Reed D. OpenID 2.0: a platform for user-centric identity management. Proceedings of the Second ACM Workshop Digital Identity Management, Alexandria, Virginia, USA, 2006; 11–16. 6. Dhamija R, Dusseault L. The seven flaws of identity management: usability and security challenges. IEEE Security and Privacy 2008; 6: 24–29. 2859
Authentication web in cloud
7. Sachs E. Usability research on federated login, September, 2008. (Available from: http://sites .google.com/site/oauthgoog/UXFedLogin) [Accessed on April 2014]. 8. Sun ST, Pospisil E, Muslukhov I, Dindar N, Hawkey K, Beznosov K. OpenID-enabled browser: towards usable and secure web single sign-on. CHI’11 Extended Abstracts on Human Factors in Computing Systems, ACM, New York, NY, USA, 2011. 9. Oh HK, Jin SH. The security limitations of SSO in OpenID. 10th International Conference on Advanced Communication Technology, 2008. ICACT 2008, Gangwon-do, South Korea, 2008; 1608–1611. 10. Laurie B. OpenID: phishing heaven, January, 2007. (Available from: http://www.links.org/?p=187) [Accessed on April 2014]. 11. Lee H, Jeun I, Chun K, Song J. A new antiphishing method in OpenID. SECURWARE, Cap Esterel, France, 2008; 243–247. 12. Urien P. An OpenID provider based on SSL smart cards. CCNC IEEE Consumer Communications and Networking Conference - CCNC, 2010; 1–2. 13. Erdos M, Cantor S. Shibboleth architecture draft v05, 2002. 14. Sharma AK, Lamba CS. Survey on federated identity management systems. In RecentTrends in Networks and Communications. CCIS, Vol. 90, Meghanathan N, Boumerdassi S, Chaki N, Nagamalai D (eds). Springer: Heidelberg, 2010; 509–517. 15. Cantor S, Kemp J, Philpott R, Maler E. Assertions and protocols for the OASIS security assertion markup language (SAML) V2.0, OASIS standard, SAML-core2.0-os, March 2005. (Available from: http://docs. oasis-open.org/security/saml/v2.0/saml-core-2.0-os. pdf) [Accessed on April 2014]. 16. Gajek S, Liao L, Schwenk J. Stronger TLS bindings for SAML assertions and SAML artifacts. Proceedings of the 2008 ACM workshop on Secure web services, New York, NY, USA, 2008; 11–20. 17. Kohlar F, Schwenk J, Jensen M, Gajek S. Secure bindings of SAML assertions to TLS sessions. 2010 ARES’10 International Conference on Availability, Reliability, and Security, IEEE, Toulouse, France, 2010. 18. Dudczak A, Helinski M, Mazurek C, Mielnicki M, Werla M. Extending the Shibboleth identity management model with a networked user profile. IT 2008. 1st International Conference on Information Technology, IEEE, 2008; 2008.
2860
G. Zhao et al.
19. Hardt D. The OAuth 2.0 authorization framework, October, 2012. (Available from: http://tools.ietf.org/ html/rfc6749) [Accessed on April 2014]. 20. Pai S, Sharma Y, Kumar S, Pai R, Singh S. Formal verification of OAuth 2.0 using alloy framework. International Conference on Communication Systems and Network Technologies (CSNT), 2011, IEEE, Harbin, China; 2011. 21. Gonzlez JF, Rodrłguez MC, Nistal ML, Rifn LA. Reverse OAuth: a solution to achieve delegated authorizations in single sign-on e-learning systems. Computers & Security 2009; 28(8): 843–856. 22. Josang A, Pope S. User centric identity management. Proceedings of AusCERT Asia Pacific Information Technology Security Conference: R&Stream, Gold Coast, Australia, May 22-26 2005; 77–89. 23. Goode J. The importance of identity security. Computer Fraud & Security 2012; 2012(1): 5–7. 24. Kormann DP, Rubin AD. Risks of the passport single signon protocol. Computer Networks 2000; 33(1): 51–58. 25. Oppliger R. Microsoft .Net passport: a security analysis. Computer 2003; 36(7): 29–35. 26. Oppliger R. Microsoft .Net passport and identity management. Information Security Technical Report 2004; 9(1): 26–34. 27. Kakizaki Y, Kazunari M, Keiichi I. Identity continuance in single sign-on with authentication server failure. Fifth International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS), 2011, IEEE, Washington, DC, USA, 2011; 597–602. 28. Kakizaki Y, Kazunari M, Keiichi I. Identifier migration for identity continuance in single sign-on. Journal of Information Security 2012; 3: 4. 29. Butler R, Welch V, Engert D, et al.. A national-scale authentication infrastructure. Computer 2000; 33(12): 60–66. 30. Burrows M, Abadi M, Needham RM. A logic of authentication. Proceedings of the Royal Society of London. A. Mathematical and Physical Sciences, 1989, 1871; 233–271. 31. Lampson BW, Abadi M, Burrows M, Wobber E. Authentication in distributed systems: theory and practice. ACM Transactions on Computer Systems (TOCS) 1992; 10(4): 265–310. 32. Bellare M, Rogaway P. Entity authentication and key distribution. In Advances in Cryptology-CRYPTO’93. Springer: Berlin/Heidelberg, 1994.
Security Comm. Networks 2016; 9:2843–2860 © 2015 John Wiley & Sons, Ltd. DOI: 10.1002/sec
