A Data Synchronization based Single Sign-on Schema Supporting Heterogeneous Systems and Multi-Management Mode Haojiang Gao 1 Beijing Northking Technology Co.,Ltd Zhongguancun Haidian Science Park Postdoctoral Workstation 2 Department of Automation Tsinghua University, Beijing, P.R.China ahustphd@yahoo.com.cn Abstract Single sign-on (SSO) solutions are classified into several modes and the flaws of each mode are pointed out in the paper. To overcome these drawbacks, a support heterogeneous systems and multi-management mode SSO (SHM-SSO) schema is proposed. Data modeling and data synchronization strategy is used in the schema to ensure subsystems run well while the Authentication Center (AC) fails and decline the intrusion into the existing systems. The schema has the advantages of agility, flexibility and anti-ac failure. It not only simplifies system management, but also protects user privacy. The schema has been put into use in a national bank in China, and exhibited satisfactory properties. Keywords-SSO; System Integration; Identity Management; Heterogeneous Systems; Data Synchronization I. INTRODUCTION With the development of IT technology, generally there are many information systems in the enterprises. These systems have their own user information management and authentication mechanism. Every user needs to remember and input his certificate into all systems, which is not only complicated, but also dangerous if the certificates are lost or disclosed. At the same time, system administrators need to do configuration in every system when employee entry or demission happens, which is inconvenient and has serious security weakness. So system integration and a portal are needed to support unified certification. In addition, with the development of B2B (Business to Business), enterprise alliance needs to lift enterprise barrier and serve customers with one portal. To satisfy these demands, more and more research focuses on single sign-on (SSO) [1-13]. SSO is a solution of access control that enables a user to log in once and gain access to the resources of multiple software systems without being prompted to log in again. But the existing SSO solutions are not perfect enough to be optimal in terms of performance, security, stability, and scale of transformation of the existing systems. In addition, few studies are concerned about C/S architecture system integration. Section 2 of this paper classifies the SSO solutions, and discusses their advantages and disadvantages. To overcome the disadvantages, section 3 designs a new SSO schema, and states its properties. Section 4 analyzes the security of the Tianyuan Xiao Department of Automation Tsinghua University Beijing, P.R.China xty-dau@mail.tsinghua.edu.cn SSO schema. Section 5 gives an application example in a national bank in China. Section 6 draws the conclusions. II. CURRENT SITUATION OF SSO RESEARCH A. SAML Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication and authorization data between security domains [2-4], that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). Assertion is a statement that does not need to be proved. The SAML assertion includes authentication assertion, attribute assertion, and authorization assertion. The single most important problem that SAML is trying to solve is the Web Browser Single Sign-On problem. SAML has been used in many web single sign-on solutions. But SAML has many disadvantages. Reference [2] points out that SAML lacks standardized mechanisms for metadata exchange, which brings many problems in practice. B. SSO solutions classification In terms of identity management mode [5-7], SSO solutions can be classified into two types. One type is identity-centric management mode (ICMM), such as Microsoft s Passport, which manages all users information in SSO Center. And the other type is liberty alliance mode (LAM), such as SAML-based Liberty Alliance Project, in which every system has its own identity management and the mapping of user accounts between systems is established. The advantage of ICMM is convenient system management. The flaw of ICMM is that it can not protect user privacy [8], because the enterprise who does identity-centric management may disclose other enterprise s userinfo. Moreover, Passport has Single Failure problem, and all systems can not work when SSO Center collapses. The advantage of LAM is that it can protect user privacy while its disadvantage is that system management is complicated and error-prone. In terms of authorization means, SSO solutions can be classified into two types. One is respective authorization mode. Each system can hold their authorization, and the SSO client or center needs to input user password as a ghostwriter. And the other type is trust transplant mode. If user has been authenticated in one system, then other systems will trust the authentication and let the user do operation. The former has 623
the advantages of small scale transformation, but its disadvantage is ghostwriting password. The advantage of the latter mode is that it does not need ghostwriting password. The flaw of the latter mode is not only that little user information is transferred, but also that it needs big scale transformation of original system. Besides the above flaws in these SSO solutions [9], we find that a few papers orient on C/S architecture system while most focus on web applications [10], and seldom consider single failure of SSO center. To overcome these disadvantages, this paper will combine the advantages of the above solutions and adopt the concept of SAML to design a set of SSO schema, which is named as support heterogeneous systems and multi-management mode SSO (SHM-SSO). The application of SHM-SSO in a China national bank will also be stated. III. SHM-SSO SCHEMA DESIGN There are many software systems in big enterprises. For example, one China national bank has dozens of applications. Each system has its own identity management, which has caused much inconvenience. So it s increasingly necessary to adopt identity-centric management. However, in enterprise alliance, enterprise does not hope to disclose their user information to other enterprises. To satisfy these demands, the SHM-SSO schema is designed to support both identitycentric management mode among the same enterprise and liberty alliance mode among alliance enterprises. On authorization, the SHM-SSO schema will also combine respective authorization mode among the same enterprise and trust transplant mode among alliance enterprises. As is previously mentioned, the identity-centric management will be used within the same enterprise, but the problem comes to how to implement respective authorization. The solution is data synchronization. A. data synchronization strategy Firstly, a system named system integration center is set up, which includes identity management center and authorization center. Identity management center manages all users information in the enterprise, even the user roles in each system, and creates data model to gain data standardization and regularization. It can ensure the consistency of data, and simplify system management. Subsystem administrators do not need to do user information management in subsystems again. And then data synchronization method is adopted to transmit the user data from identity management center to other subsystems. By data synchronization, the data of the user who has subsystem roles, including encrypted user password, will be transmitted to the corresponding subsystem. Then subsystem will convert the received standardization data to its local characteristics data type and store them into database. It should be noted that user accounts mapping data between systems is not stored in system integration center so as to simplify system management. System integration center provides the unified identifier, such as user ID number. Subsystems match the same user in their own database by the unified identifier. A universal plug-ins has been developed to implement the data synchronization function, which can be nested into subsystems and subsystems only need to implement some simple interface. The interface is used to convert the received standardization data to its local characteristics data type. And the code of writing and reading database in subsystems can be preserved. So it makes almost no intrusion into the existing systems. Web services technology is used in data synchronization. System integration center is web services provider [11], and subsystem is web services client. As is illustrated in Fig.1, each subsystem pulls and stores relative data on a regular time schedule, and puts the user data into workflow systems it uses. Moreover, once the data changes, the identity management center will notice the relative subsystem to synchronize the changed data immediately. Then a pull and push data synchronization has been implemented. Chaotic encryption algorithm is used to protect the data synchronization communication [12]. Specially, the function of data synchronization and SSO is designed and coded as an SSO component, which can be nested into subsystems, and subsystems only need to implement some simple interface. Why is data synchronization used? The reasons are as follows. (1)Subsystems need to record user operation log, and the user table in database will be used by some foreign keys. (2) Subsystems statistics need use of organization table and user table. (3) Subsystems do authentication in their own way. If no relative data is available, subsystem need big scale transformation. Thereby identity-centric management and respective authorization is the first choice. As for enterprises alliance, to protect user privacy, the choice will be changed into trust transplant in which trust is transplanted between authorization centers. B. supporting heterogeneous systems and domain-crossed SSO communication According to the concept of SAML, the SSO communication procedures among one enterprise s systems are as follows. (1)As is shown in Fig.2, user submits his certificate and logs in authentication center (AC). (2) AC creates an encrypted authentication token and sores it into the user s session and cookie. (3) The user requests service of target system (subsystem). (4) Target system detects that the user has not logged in. Then it generates a random number, and stores it into the user s session. (5) The target system redirects the user to AC and requests authentication assertion. (6) AC extracts and decodes authentication token from user s session or cookie, then checks its validity. If the token is verified, AC responds authentication assertion and attributes assertion (maybe encrypted password) to the target system by encrypted URL. (7) The target system accepts and decodes the assertion, and checks the validity of the assertion and the random number in the user s session.iftheyare valid, it removes the random number form user session, and loads the user information and roles from its own database into the user s session. (8) Then the target system shows the pages that the user requested in step (3). After that, when the user request the same target system, it will show response 624
directly without asking the AC for authentication assertion until the session times out. If target system is based on C/S architecture, it is needed to set up a middle web server, which includes the SSO component and provides a JSP page nested with a Java applet. Then SSO communication steps will have the following changes. In step (3), user requests the JSP page. In step (7), the SSO component will attain the authentication assertion and attribute assertion. In step (8), the Java applet will be responded to user, and it will connect to the middle server immediately and gets username and password. Java applet is signed by middle server, so it cans startup the C/S client application and input user account and password as a ghostwriter. Experimental verification shows that the communication steps are feasible. Fig.3 shows the SSO communication steps between alliance enterprises by trust transplant. (1)User logs in enterprise1 s AC1. (2) AC1 creates an encrypted authentication token and sores it into the user s session and cookie. (3) The user requests service of target system (subsystem) which belongs to enterprise2. (4) The target system detects that the user has not logged in. Then it generates a random number, and stores it into the user s session. (5) The target system redirects the user to AC2 and requests authentication assertion. (6) AC2 does not find its SSO token, and redirects user to AC1. (7) AC1 extracts and decodes authentication token from user s session or cookie, and checks its validity. If the token is valid, AC1 creates another random token, and sends it to AC2. (8)AC2 accepts the token, and requests AC1 for SAML assertion with the token. (9) AC1 checks the validity of the token and sends encryptedsamlassertiontoac2.(10)ac2decodesthe assertion and extracts the user info. If the user does not exist in AC2, it will save the user s information to database, and notices relative subsystems to do data synchronization. (11) AC2 redirects user to the target system with authentication assertion. (12) The target system accepts and decodes the assertion. (13) The target system shows response. C. features of SHM-SSO schema The SHM-SSO schema has the following advantages. (1) It can implement SSO between heterogeneous systems. (2) It supports multi-management mode, and has the advantages of both identity-centric management mode and liberty alliance mode. And it satisfies the demand of data centralization in the same enterprise and privacy protection between enterprises. (3) Flexibility. The authentication trust can be transplanted between authentication centers. (4) Easy to integration legacy systems. The authentication and authorization code of legacy system can be reserved. (5) It has excellent ability of anti single point of failure. Even when the authentication center collapses, the subsystems can work on. This is because every subsystem stores user data. (6) Loosely coupled relationship between authentication center and subsystems brings convenience of development of new subsystem. However, the SHM-SSO schema uses data synchronization. But as standard data model has been set up and a universal data synchronization plug-ins has been developed to be nested into each subsystem, data synchronization does not cause much inconvenience. IV. SECURITY ANALYSIS OF SHM-SSO SCHEMA The communication showed in Fig.2 and Fig.3 is secure for the following reasons. To begin with, system integration center is separated from subsystems, so SSL protection can be added to the whole domain of the system integration center. Besides, steps (2), (5), (6) in Fig.2 and steps (2), (5), (6), (7), (8), (9), (11) in Fig.3 use chaotic encryption algorithm and random number check [12]. And these measures can protect message far away from theft and distort. Replay attack can also be prevented by the following reasons. (1) Each assertion has set validity duration, which is often 30 minutes. (2) Target system has set random number in user s session before assertion request, and will check the random number in the user s session and assertion before accepting an assertion. In addition, it will remove the random number from the user s session. So replay attack can not work. For the same reason, the schema can prevent Man-inthe-Middle Attacks [13]. The data synchronization is also secure. This is because that the communication is protected by chaotic encryption. Furthermore, user password is encrypted separately and there is no decryption algorithm given for the systems, and so the password can not be decrypted. V. APPLICATION EXAMPLE A financial system based on the SHM-SSO schema has been put into use in a China national bank in September, 2008, which has about 20 province s users. The user logs in through SSO Center and then menus of subsystems that he can access are listed. In the process, SSO Center kicks off thesameuser s login in other places and other user s login in thesamebrowser. The SSO Center also has function of single log-out. Once user clicks log out button, SSO Center will remove the user s session and cookie, and notice every subsystem that he accessed to log out the user. Moreover, even if user forgets to click log out button, the SSO Center will log out the user when following conditions are met: (1) User has logged out all subsystem that he has accessed or his session times out in all these subsystems. (2) His session in SSO Center times out. When SSO Center has a breakdown or a new subsystem is being developed, subsystem administrator only needs to set the attribute of SSO-function-enable to false, and then the subsystem can run independently. Furthermore, user can log in the subsystem with his certificate in the SSO Center. The SHM-SSO schema implements centric and unified management of identity, organization and user-role. It has eliminated inter-system inconsistent data, reduced administrative costs, simplified the operation, improved the productivity and security, and has good scalability and disaster recovery ability. These properties satisfy the customers. 625
VI. CONCLUSIONS Application practice has proved that the proposed SHM- SSO schema has the advantages of agility, flexibility and anti-ac failure. It has implemented centric data management in each enterprise and privacy protection between enterprises. Furthermore, it can integrate both B/S architecture system and C/S architecture system. Data synchronization mechanism enables SSO Center to make almost no intrusion into the existing systems, and enables subsystem to work while the SSO Center fails, which shows good disaster recovery ability. Furthermore, its excellent performance in the national bank in China implicates potential future application of the schema in many big enterprises. ACKNOWLEDGMENT We thank the supports and grants of Zhongguancun Haidian Science Park Postdoctoral Workstation. REFERENCES [1] A. Volchkov, Revisiting single sign-on a pragmatic approach in a new context, IT Professional, vol. 3, no.1, pp. 39-45, 2001. [2] P. Harding, L. Johansson, and N. Klingenstein, Dynamic security assertion markup language: Simplifying single sign-on, IEEE Security and Privacy, vol. 6, no. 2, pp. 83-85, 2008. [3] E. Vullings, J. Dalziel, and M. Buchhorn, Secure federated authentication and authorisation to GRID portal applications using SAML and XACML, Journal of Research and Practice in Information Technology, vol. 39, no. 2, pp. 101-113, 2007. [4] H. Tschofenig, R. Falk, J. Peterson, J. Hodges, D. Sicker, and J. Polk, Using SAML to protect the Session Initiation Protocol (SIP), IEEE Network, vol. 20, no. 5, pp. 14-17, 2006. [5] G. Goth, Identity management, Access specs are rolling along, IEEE Internet Computing, vol. 9,no. 1, pp. 9-11, 2005. [6] D.A. Buell, and R. Sandhu, Identity Management, IEEE Internet Computing, vol. 7, no. 6, pp. 26-28, 2003. [7] V. Poursalidis, and C. Nikolaou, Towards a person-centric identity management infrastructure (IMI), Computer Systems Science and Engineering, vol. 22, no. 5, pp. 255-266, 2007. [8] P. Birgit, Privacy in enterprise identity federation - policies for Liberty 2 single sign on, Information Security Technical Report, vol. 9, no. 1, pp. 45-58, 2004. [9] T. David, Biometrics and single sign-on, Biometric Technology Today, vol. 13, no. 8, pp. 8-9, 2005. [10] S. Chu, D.N. Good, M.R. Mamajek, and D.J. Washington, Webbased single sign-on solutions: an SSO product matrix, Computer Security Journal, vol. 16, no. 1, pp. 39-49, 2000. [11] D. Zheng, S. Tang, and S. Li, Web Services single sign-on protocol and formal analysis on it, Journal of Circuits, Systems and Computers, vol. 14, no. 5, pp. 923-930, 2005. [12] H. Gao, Y. Zhang, S. Liang, and D. Li, A New Chaotic Algorithm for Image Encryption, Chaos, Solitons and Fractals, vol. 29, no.2, pp. 393-399, 2006. [13] P. Birgit, and W. Michael, Analysis of Liberty Single-Sign-on with Enabled Clients, IEEE Internet Computing, vol. 7, no. 6, pp. 38-44, 2003. Figure 1. Data Synchronization 626
Figure 2. SHM-SSO Schema Timing Chart Figure 3. Enterprise Alliance SHM-SSO Schema Timing Chart 627