Proposal of a standard mutual authentication system in a virtual organization Amadou Dahirou Gueye1, Davy Edgard Moussavou2, Samuel Ouya3, Hamadou Saliah-Hassane3 and Claude Lishou3 1
Alioune Diop University, Bambey, Senegal,
[email protected] Cheikh Anta Diop University, Dakar, Senegal,
[email protected] 3 Cheikh Anta Diop University, Dakar, Senegal,
[email protected] 3 TELUQ |University of Quebec, Montreal, Canada,
[email protected] 3 Cheikh Anta Diop University, Dakar, Senegal,
[email protected] 2
Abstract Usually, traditional organizations were autonomous and had the choice to use any authentication method to authenticate their users. Today, this resources sharing may raise the problem of heterogeneous authentication methods. Some researchers proposed data mapping methods for authenticating partner organizations. However, various authentication methods and the need for a collaborative virtual organization increasingly large complicate this approach. Hence, we propose a standard mutual authentication system between organizations which covers also the aspects like integrity, confidentiality and repudiation through a peer to peer model as well as a centralized model based on a trusted third party. The relevance of our approach was demonstrated through a virtual organization where users authenticate themselves from their home organization to access to online laboratoryresources while respecting the authentication method of the remote organization.
Keywords:
Virtual Organization, Laboratory, Resource Management.
Collaboration,
Authentication,
Online
1. Introduction Today most universities and/or industries are trying to establish collaborative networks through virtual organization (VO) by mutualising the resources of their laboratories. In the literature, there are several definitions of VO [1]. The key characteristics of VO are: usage of ICT, geographical dispersion, core competencies and dynamic network. In this paper, we propose a solution to the issue of authentication within a virtual organization in context of online laboratories. Several studies and projects have dealt with remote laboratories, a subset of online laboratories[2][3][4], each lab having its own authentication system. So, in the collaboration between remote labs, there will be the issue of how to establish an authentication standard that will ensure transparent authentication for the access to resources. The authentication standard we are proposing will be applicable to all forms of VO. The question then is how to make it possible for International Conference on Engineering Education and Research 1 July - 5 July 2013, Marrakesh
authentication systems of different remote labs to communicate without modifying their respective authentication systems. The section 2 deals with the state of the arts in the field of authentication management within VOs. The section 3 is about the standard as proposed through two authentication models. The section 4 gives a description of the communication diagram. The section 5 is about the findings. The conclusion recapitulates results and opens door to further discussions.
2. Related work Usually, VOs are implemented through Grid computing [5][6][7]. The problem of security for grid computing system is solved by using globus toolkit [8][9]. In the same way, universities use shibboleth to manage the identities of their members within collaborative network for the purpose of sharing pedagogic resources. The operation of the shibboleth system and the interactions between the various components is described in [10][11]. Also, the PKI approach is widely used in grids computing [12][13]. In [8], the authors compare and evaluate authentication mechanisms used in three architectures based on certain criteria like usability, administration, mobility and others. The analysis of these authors shows that PKI based authentication based highly takes into account the criteria of performance of an authentication system, with the implied constraint that every member organization will have to trust a common certification authority. The PKI approach fits very well globus toolkit. In our point of view, deploying a PKI is expensive and it management is considered a serious challenge when the number of partners increase progressively. In addition, deploying a PKI means that users are authenticated on their sites by providing their identity certificates managed by the PKI. This implies that each partner has to modify his authentication system and adopts the PKI, which is like adding a constraint to each partner. This led us to explore another approach namely the so-called ontology based mapping as proposed in [14]. Indeed, the approach helps to achieve common results for authentication within a VO from the characteristics used by the authentication systems of each partner organization. Details of this method are given in [14].This approach can be complicated to deploy when the number of partners increase progressively. Also, do not cover the aspects like confidentiality, integrity and repudiation. We think it’s possible to link the PKI approach with mapping as proposed in [14]. In this paper, we propose to use the mapping method to build common authentication identities for users when they access remotely on shared resources within the VO. In our proposal, we introduce a trusted third part which will act as identity converter between the members of a VO, and setting up an authentication facility which complies with the authentication systems of the various organizations while guaranteeing confidentiality, integrity, and repudiation. The relevance of our approach will be demonstrated by authenticating users in the context of remote labs.
3. Proposal for an authentication model To manage the authentication in various sites of VO, we propose an architecture based on two models: the peer to peer model and the centralized model. International Conference on Engineering Education and Research 1 July - 5 July 2013, Marrakesh
3.1. Peer to peer model What we call home server is an authenticator server which will authenticate the users of each site who wish to access the resources of the VO. It will play the role of an identity converter through information mapping of the user. So, each user must have a VO authenticator client installed in his computer to communicate with the authenticator server of his home site. The authenticator servers of each site must be interconnected through a trust relationship. This assumes that VO members must build a chain of trust between them. The issue trust between members already addressed on [15]. Home Resource Provider (HSP) (2)
(5) (1) (6)
(3)
user
Home authenticator Server (HAS)
Home authenticator server (HAS)
(4)
(7)
Home Resourcee Provider
Figure 1. Peer to peer authentication model
The peer to peer model is described as followed in Figure2. Client
RO SERVER
Start
RO SERVER
Start
Encrypt by user Secret(Username
AuthUserRequest (PrivateInfo,P ublicInfo)
Decrypt by user secret and Check(PrivateInfo,Publi cinfo)
,Ressource)
GetAuthRespon se()
Start
AuthUserReJect(code)
Forwarding Request (PrivateInfo ,PublicInfo)
No match
Decrypt by user secret and Check(PrivateInfo,P ublicinfo)
Yes
CheckSecurityPolicies( Username,Ressource)
No match
AuthUserDeny(code)
Yes No
Allow Yes No Local ressource
Encrypt by Remote Secret(Usernam e,Ressource)
ChecResource Availability(Re ssource)
Yes
ChecResource Availability(Re ssource) AuthUser-Accept()
ForwardingReJect(code) GetAuthForwardR eponse
Avaiable
No
Ressour ceUnav ailable()
No Authenticate and Ressource Avaible
Yes
GetAuthSessionInf ormation()
CloseSession()
End
Yes
Ressource Unavailabl e()
No
No
Avaiable
Yes Authenticate and Ressource Avaible
SendSessionK ey(SessionInfo )
ConnectoRessource( ressource)
ForwardSessio nKey(SessionI nfo)
CloseSession( )
Yes
GetAuthSessionInf ormation()
CloseSession()
End
SendSessionK ey(SessionInfo )
CloseSession( )
CreateSessionInfo raton(Username,U serOrg)
CloseSession()
End
Figure 2. Peer to peer algorithm International Conference on Engineering Education and Research 1 July - 5 July 2013, Marrakesh
So, when a user wishes access to remote resource within VO; firstly, the user must be authenticated from his home authenticator server through his VO authenticator client. This client will provide user’s credentials to the home authenticator server by generating public and private information, to ensure data confidentiality between client and home server. The client encrypts the login and the resources with authenticator server’s public key to obtain the public information. After obtaining this, the client will obtain the private information with his user’s secret. The user’s secret may be a digital certificate or condensed data to ensure integrity and repudiation between client and his home server. The foundation of our approach is strongly based on the globus toolkit and shibboleth mechanisms; the difference is that the user is invited to authenticate first at their own home server which will then redirect the request to remote resource provider in case the resources are not local. This implies that the resource addressing must indicate the organization to which the resource belongs. The resource may be software or hardware. 3.2. Centralized authentication model The centralized model is an extension of peer to peer mode. This model has three components: the home authenticator server, the trusted third party, the remote authenticator server. Firstly, each home authenticator server can be considered as an authenticator client like in the peer to peer model; secondly, the trusted third party can be considered like home authenticator server. The same mechanism can be implemented between trusted third party and the remote authenticator server. The relevance of our approach lies in the fact that it does not necessary change the home site authentication systems. This approach can be regarded as a new layer to add in the local authentication system to remote access in VO.
user Remote authenticator server
Resource
Trusted third party
Home authenticator server
Figure 3. Centralized authentication model
The centralized authentication model is described in the Figure 4 as below:
International Conference on Engineering Education and Research 1 July - 5 July 2013, Marrakesh
Resource (1') User
Remote authenticator server
by
ue s r e t to so u u r se ce t
eq R
authentication information to the user - user identifier ( includes home organization’s name) - Resource
by
encrypt
(2)
he
creates
System visited secret
Public information Private information between user and home organization
-
user identifier resource optionCA home server name remote server identifier
- user identifier - syst. Visited identifier
encrypt (3)
User secret Private information between user and home organization
Trust third party
(1)
encrypt
(4)
by
Trust third party secret
Public information Private information between user and home organization
-
user identifier resource optionCA home org’s name syst. Visited identifier
- public information - trust third party’s name
(5)
Home authenticator system
Figure 4. Authentication process in centralized model
4. Communication diagram The proposed approach aims be a standard for mutual authentication within VO. Therefore, we designed a protocol to implement the proposed model. In this section, we present the possible client request and how the server will respond. When a user wishes to authenticate, the user’s client will sent AuthUser-Request message with two arguments as follow: AuthUser-Request [Private Info] [Public Info]. The server’s responses may be AuthUser-Accept, AuthUser-Reject or AuthUser-Deny. The message AuthUser-Accept is sent back to the user after the user has been successfully authenticated like this: AuthUser-Accept [sessionkey]. When the user provides a wrong crendentials, AuthUser-Reject is sent back to the user with an error code. The message AuthUser-Deny is sent back when the user tries to access unauthorized resources an error code. When the user applies for resource unavailable in home organization server, this message AuthForward is sent to remote authentication server. One of the following responses may be sent back to home organization server: Authuser-Forward-Accept, Authuser-Forward-Reject. The message Authuser-Forward-Accept is sent back when the resource is available at the level of the organization holding the resource and the user’s session key was successfully created. Syntax: AuthUser-Forword-Accept [Sessionkey] [Orgname]. User
Organisation-Origine
Organisation-Partenaire
AuthUser-Request AuthForward
AuthUser-Accept
AuthUser-Forward-Accept
Figure 5: Response of type AuthUser-Forward-Accept
International Conference on Engineering Education and Research 1 July - 5 July 2013, Marrakesh
The message Authuser-Forward-Reject is sent back when the resource is unavailable at the level of the organization holding the resource and the user’s session key was unsuccessfully created. User
Organisation-Origine
Organisation-Partenaire
AuthUser-Request AuthForward
AuthUser-Reject
AuthUser-Forward-Reject
Figure 6: Response of type AuthUser-Forward-Reject
5. Results The proposed standard had implemented by the simulation our protocol. First, the question was how to authenticate a user member of a VO. we design a client and authenticator server based on PAM Linux modules.To assure confidentiality, integrity and repudiation aspects, we used RSA_private_encrypt and RSA_public encrypt function [16], in order to enable the client to encrypt his private and public information’s before to send them to his home server. These functions are also used in both home server and remote server side. Thus, to achieve our goal, we have implemented a virtual organization composed by two partners labs, LIRT in Dakar and L@D in Montreal. The authentication model proposed allows users to authenticate from their respective home organization to access to online laboratory resources s while complying with the authentication method of the remote organization which provide the resources. To do this, a simulation was made to authenticate to user «davy» using the peer to peer model. We tested the access to a remote router through ssh protocol. LABADER LIRT-ESP/UCAD
1
7 lirt-esp.ucad.sn
2
3
4
6 Router.lad.licef.ca
5 Authenticatorserver.lad.licef.c a
davy-lirt.ucad.sn
Figure 7 : Simulation architecture
Step 1: The user launches the authenticator client on his computer davy@pc-davy:/VO$./VO-client lirt-esp.ucad.sn Username :
[email protected] Passwrd :motdepasse Ressource(e.g :servicename@organisation) :
[email protected] Authentification pending...
Step 2: Receiving credentials from the authenticator client Receive from : 192.168.1.16 Username :davy Organisation :lirt-esp.ucad.sn Ressource name :ssh Destination Org : lad.licef.ca
Step 3: The home organization transfer the request to remote resource provider. Forwarding the request to :lad.licef.ca Username:davy
International Conference on Engineering Education and Research 1 July - 5 July 2013, Marrakesh
User Org:lirt-esp.ucad.sn Ressource:ssh Sequence number:102 Org Name : lirt-esp.ucad.sn
Step 4: The server receives lad.licef.ca information, check the availability of the router and then generates a session key. Step 5: The lad.licef.ca server sends the session key to lirt-esp.ucad.sn. The session key contains information to allow the user to access on remote router. *****************RECEIVE SESSION KEY FORM: lad.licef.ca************** Requestid: 103 Session ID: 1962 Username: davy-lirt-esp-ucad Durations: 3600s Resource name: router.lad.licef.ca Session Key issue by: lad.licef.ca
Step 6: The lirt-esp.ucad.sn server will connect to remote ssh by ssh protocol using the user session key, the opened session will be forward to user.
6. Conclusion and Discussions In this paper addressed the issue mutual authentication within VO, considering the fact that, each partner of VO has his own authorisation system. The aim of the proposed approach is not to change partner authentication system, but is to add new layer in each authentication system. In that way, any organization can join or leave without compromise the security of VO. We described the two proposed models, and we show the communication diagram between each component of our models. Also, we described the main results. One of contribution of this paper is the fact that, our proposal can be apply to any VO type, and the fact that we apply it to online laboratory could encourage the universities and other industries to create VO without be concern by the issue of heterogeneous authentication methods. Another contribution is the integration of security aspects like confidentiality, integrity and repudiation. The future work will address how the authenticator server will synchronize dynamically all information when new authenticator server join or leave VO. Furthermore, today, one of the research problems is also online laboratory evolution VO in the cloud computing while managing security aspects [17].
7. References [1]
B. S. E, “The Virtual Organization,” Futurist, pp. 9–14, 1994.
[2]
H. H. Saliah, L. Villardier, C. Kedowide, and B. A. T. Wong, “Session T1D RESOURCE MANAGEMENT STRATEGIES FOR REMOTE VIRTUAL LABORATORY EXPERIMENTATION Session T1D,” pp. 8–12, 2000.
[3]
F. Lerro, S. Marchisio, S. Martini, H. Massacesi, E. Perretta, a. Gimenez, N. Aimetti, and J. I. Oshiro, “Integration of an e-learning platform and a remote laboratory for the experimental training at distance in engineering education,” 2012 9th International Conference on Remote Engineering and Virtual Instrumentation (REV), pp. 1–5, Jul. 2012.
International Conference on Engineering Education and Research 1 July - 5 July 2013, Marrakesh
[4]
H. Saliah-Hassane, I. de la Teja, and O. Dioume, “On-line Laboratory Brokerage System for Education and Research,” jee.asee.org, pp. 1–9, 2003
[5]
A. Squicciarini, “Access control strategies for virtualized environments in grid computing systems,” Computing Systems, pp. 48–54, Mar. 2007.
[6]
J. Calvillo, I. Román, S. Rivas, and L. M. Roa, “Privilege management infrastructure for virtual organizations in healthcare grids.,” IEEE transactions on information technology in biomedicine : a publication of the IEEE Engineering in Medicine and Biology Society, vol. 15, no. 2, pp. 316–23, Mar. 2011.
[7]
J. Zhan and H. Zhang, “Trusted Computing Enabled Access Control for Virtual Organizations Current Security Practice for the Grid,” pp. 494–497, 2007.
[8]
A. N. Haidar and A. E. Abdallah, “Comparison and Evaluation of Identity Management in Three Architectures for Virtual Organizations,” 2008 The Fourth International Conference on Information Assurance and Security, pp. 21– 26, Sep. 2008.
[9]
P. C. Moore, W. R. Johnson, and R. J. Detry, “Adapting Globus and Kerberos for a Secure ASCI Grid,” no. November, 2001.
[10]
W. Ying, “Research on Multi-level Security of Shibboleth Authentication Mechanism,” 2010 Third International Symposium on Information Processing, pp. 450–453, Oct. 2010.
[11]
S. Fujiwara, T. Komura, and Y. Okabe, “A Privacy Oriented Extension of Attribute Exchange in Shibboleth,” 2007 International Symposium on Applications and the Internet Workshops, pp. 28–28, Jan. 2007.
[12]
G. Liu, “Using Security Proxy Based Trusted Computing Enhanced Grid Security Infrastructure,” Information Engineering and Computer Science, 2010.
[13]
R. O. Sinnott, D. W. Chadwick, T. Doherty, D. Martin, a. Stell, G. Stewart, L. Su, and J. Watt, “Advanced Security for Virtual Organizations: The Pros and Cons of Centralized vs Decentralized Security Models,” 2008 Eighth IEEE International Symposium on Cluster Computing and the Grid (CCGRID), pp. 106–113, May 2008.
[14]
S. Muthaiyah and L. Kerschberg, “Virtual organization security policies: An ontology-based integration approach,” Information Systems Frontiers, vol. 9, no. 5, pp. 505–514, Oct. 2007.
[15]
M. Kamel and R. Laborde, “A best practices-oriented approach for establishing trust chains within virtual organisations,” … Workshops, 2008 12th, 2008.
[16] J. V. Matt Messier, Secure Programming Cookbook. 2003, p. 784. [17] M. Saad, W. Ofosu, and W. Campus, “AC 2011-2530: LAB@ HOME: REMOTE LABORATORY EVOLUTION IN THE CLOUD COMPUTING ERA,” jee.asee.org, 2011. International Conference on Engineering Education and Research 1 July - 5 July 2013, Marrakesh
