软件应用中英文对照外文翻译文献
软件应用中英文对照外文翻译文献
(文档含英文原文和中文翻译)
原文:
The Design and Implementation of Single
Sign-on Based on Hybrid Architecture
Abstract—For the purpose of solving the problems of user repeated logon from various kinds of Application which based on hybrid architecture and in different domains, single sign-on architecture is proposed. On the basis of analyzing the advantages and disadvantages of existing single sign-on models, combined with the key technology like Web Service, Applet and reverse proxy, two core problems such as single sign-on architecture mix B/S and C/S structure applications and cross-domain single sign-on are resolved. Meanwhile, the security and performance of this architecture are well protected since the reverse proxy and related encryption technology are adopted. The results show that this architecture is high performance and it is widely applicable, and it will be applied to practical application soon.
Index Terms—single sign-on, web service, cross domain, reverse proxy, B/S, C/S
INTRODUCTION
With the information society, people enjoy the progress in the huge interests, but at the same time also faced the test of information security. With all system users need to log in the system increased, users need to set a lot of user names and passwords, which are confused easily, so it will increase the possibility of error. But most users use the same user name and password, this makes the authentication information is illegally intercepted and destroyed the possibility of increased, and security will be reduced accordingly. For managers, the more systems need more corresponding user databases and database privileges, these will increase management complexity. Single sign-on system is proposed a solution to solve the problem. Using single sign-on, we can establish a unified identity authentication system and a unified rights management system. It not only improve system efficiency and safety, but also can use user-friendly and to reduce the burden on administrators.
TABLE 1 The comparison of a variety of single sign-on to
achieve models
SSO Achieve-
Model Action ability Manageability
The large
transformation of the Enable centralized management Broker Model
Agent Model
old system Need to add a new agent for each of the old system, transplantation is
relatively simple Management more difficult to control
Agent and
Broker Model
Transplantation simple, transformation of the
old system with Enable centralized management
Gateway Model
limited capacity Need to use a dedicated gateway to access various Easy to manage, but databases between the different gateways need
to be synchronized
Need to add new
components and
increase the Token Model applications Implementation of relatively simple
management burden
Single sign-on refers to when the user needs to access a distributed environment which has different applications to provide the service, only sign on once in the environment,no need for the user to re-sign on the various application systems[1]. Now there are many products and solutions to implement SSO, such as Passport of Microsoft, IBM Web Sphere Portal Server although these SSO products could do well in the function of single sign-on, but most of them are complex and inflexible. Currently, the typical models to achieve SSO include broker model, agent model, agent and broker model, gateway model and token model [2]. In table 1, it analyses these models can be implemented and manageability. Based on the above comparison, agent and broker model has the advantages both centralized management and revised less original application service procedure. So I decide to adopt agent and broker model as the basis for this model. In order to integrate information and applications well and with the B/S mode in-depth application software, there has been the concept of enterprise portal, offer a best way to solve this problem. Enterprise portal provides business users access information and
applications, and complete or assist in a variety of interactive behavior of a single integrated access point. The appropriate system software portal provides a development, deployment and management of portal applications services. Enterprise information portal concerns portal, content management, data integration, single sign-on, and much other content.
SYSTEM CONSTRUCTION WHICH REGISTERS BASED ON THE
WEB SERVICE MIX CONSTRUCTION SINGLE SIGN-ON
The system consists of multiple trust domains. Each trust domain has much B/S architecture of the application servers; in addition to B/S architecture of the application servers also included C/S architecture application servers. All the applications are bound together through a unified portal to achieve functionality of single sign-on. You can see that this architecture is based on the agent and the broker model. A unified agent portal is playing a broker role, and various applications are playing an agent role. The B/S architecture applications are installed on the Client side of SSO Agent, and the unified portal is installed on the Server side of SSO Agent. Between them is through these two Agents to interact. In addition, in Fig 1, the external provision of authentication server is LDAP authentication interface. Token authentication Web Service server provides the interfaces of single sign-on token of the additions, deletions, editions and queries. But the permission Web Service server provides the appropriate authority information system, to achieve unified management authority for accessing unified portal application system.
The system supports cross- domain access, that is, the domain D1 users can access the application domain D2, and the domain D2 users can access the application domain D1. At the same time, the system also supports the application of different structures between the single sign-on, that is, user after accessing the application A of the B/S structure access the application E of C/S structure without having to repeatedly enter user name and password, or user access the application A after the application E without re-enter login information.
The whole structure of Single Sign-on is as Fig 1 shown.
Figure 1: The Structure of Single Sign-on
A. The login process
The whole single sign-on process is as Fig 2 shown: Below is the process specific steps description:
1)User login in the client browser to access A application, SSO Client of A system intercept and redirect the URL to the landing page of Unified Portal System
2)Enter the user name and password, Unified Portal System submits to the authentication server for authentication. If the information is correct, Unified Portal System automatically generates, saves notes and the role of the user ID to a local, and calls the increate-note interface of Web Service to insert the information.
3)Unified Portal System returns a list of application resources pages to the user. The user clicks any one application system (e.g. A system). The SSO Client-side of A application system read the notes information and call the query-notes interface of Web Service. If it is consistent and within the time limit, it will get the role information of the user in A application system and log in A application system. At the same time, it will call the update-note interface of Note Certification Web Service to update the log-in time of this current note. Then call the interface of user rights Web Service to get this user‟s permission information with corresponding application system.
4)If user end to access A application system, exit and click on the link of B application system, system implementations will be are as the same as steps (3).
5)If user complete all the required access-applications and need to do the log-off operation, it will mainly call the deletion-note interface to destroy the corresponding note information.
Figure 2: The whole process of Single Sign-on
B. The solution of Cross-domain problems
In the traditional implementation of single sign-on system will be generally used cookie as storage of client-side notes, but because of restrictions on cookie itself properties make it only on the host under the same domain effective, and distributed application system always can not guarantee that all hosts under the same domain. The current system does not store the note information in the client-side but placed various application parameters of the link directly. The note-verification is through the application of the SSO Client-side call to the corresponding interface of Web Service to complete.
Through the Simple Object Access Protocol (SOAP) to provide software service in the Web, use WSDL file to illuminate and register by UDDI [3]. Shown in Fig 3, after the user through the application of UDDI to find a WSDL description of the document, he can call the application which through SOAP to provide by one or more operations of Web services. The biggest characteristic of Web Service is its cross-platform, whether it is the application of B/S structure or C/S structure, whether it is the application using J2EE or .NET to implement, it can access Web Service as long as to give Web Service server's I:P and interface name.
The following is this system process of achieving cross-domain access:
1)User log in Unified Portal system successfully.
2)User accesses A application system within the trusted domain D1, complete the access and then exit this application.
3)User clicks the URL of B application system within trusted domain D2 of the resources list of Unified Portal.
4)SSO Client of B application intercepts the request, gets the note behind URL, and calls the query-note interface of Web Service.
5)Query interface of Web Service gets back the legal information of this note to the SSO Client.
6)SSO Client redirect to B application system, the user access B application.
Figure 3: Web Service Structure
C. The Solution of Single Sign-on between B/S and C/S Structures
As we know, the implementation principles of applications are quite different between B/S and C/S structures. In this system, the applications of B/S structure can be accessed through by clicking URL of the application-resources-list page of Unified Portal. Since the browser security restrictions, the page does not allow users to directly call the local exe files, so need to adopt an indirect way to call C / S architecture applications. This article uses the way of Applet to call local exe files, the implementations as below:
For all C/S structures, create a common Agent. This Agent's role is an interceptor, which means it need browsers to access after the C/S structure joined up Unified Portal system. (Please note that: Since the original B/S architecture and C/S structure is not using the same authentication method. For the C/S application access to the unified portal framework to achieve single sign-on system, the need for a unified authentication management, and in order to change the amount of compression to a minimum. Implementation of this system is to create a needless user name and password authentication code for all applications which are accessed a unified portal, and land on the unified portal system certified landing page. When a user uses browser to log into the unified portal system successfully and then can access any application, including the B/S architecture and C/S structure of the application. To be ensure the security of C/S application framework, when the user clicks directly to the desktop shortcut to open applications still using the original authentication.)
Applications of C/S architecture are all using the same Applet of URL. The received parameters of this common Applet include bills, application name, unified login-name and password. When a user does not do the login operation before, the first visit a C/S application will be intercepted to the login-page of Unified Portal system for sign-on. If a user logged in before, when visiting a C/S application, this Agent will call the interface of Web Service note-validation to validate the note which was transferred. If the validation is
successful, Applet object will be downloaded to the user's local to implement. In order to transform the original applications as little as possible, the method of this article is to open the login window of the corresponding application through by Applet. Below are the codes:
public void OpenExe(String appName){ Runtime rn=Runtime.getRuntime();
Process p=null;
p=rn.exec(“c:\.” + appName + “.exe”);
}
After opening the log-in window of the application, the operation steps of this Applet as follows:
1)Applet needs to call the bottom API of windows to get the user-name of login window, password-input box and the handle of login button through by JNI.
2)Locate the user-name-input box to send unified login name. Locate password-input box to send the password. (Password information is arbitrary and in order to distinguish it from the user clicks on a shortcut directly landing system, also need to send a code that uses a unified portal access without a password authentication system.) Locate the login button to send the click event.
3)At last, Applet will minimize the IE window, the related windows of applications will be placed to the forefront.
These are the implementation process of C/S architecture application single sign-on. The application codes which have not been changed at all before will join up the Unified Portal system using a loosely coupled way. Need to explain that, due to the Applet JVM security restrictions, cause Applet can not directly call the user's System32 directory of local native windows dll. Now the method is first to start to use C or C + + to write the class which got the corresponding input box and button of the login window, and generate a JNIWindowUtil.dll file (JNIWindowUtil is a user-defined dll's name). And it is to place the dll in the same directory with the Applet. When the Applet is downloaded to the client side, dll is also downloaded to the user's System32 directory of local at the same time. Applet process also needs to execute statement: System.loadLibrary("JNIWindowUtil"). After completing these above steps, it can really use JNI in Applet internal to achieve the corresponding functions.
D. Authentication server
The old system user authentication information is usually stored in a database, but this architecture used LDAP to store user information. LDAP, short for Lightweight Directory Access Protocol, is the standard directory access protocol based on a simplified form. It also defines the way data organization; it is based on TCP/IP protocol of the de facto standard directory service, and has distributed information access and data manipulation functions. LDAP uses distributed directory information tree structure. It can organize and manage various users‟ information effectively and provide safe and efficient directory access.
Compared with the database, LDAP is the application for reading operation more than writing operation, and database is known to support a large number of writing operations. LDAP supports a relatively simple transaction, but the database is designed to handle a large number of various transactions. When the query in Cross-domain data is mainly read data, modify the frequency is very low. When Cross-domain access to the transaction, it does not require a large load, so in comparison with the database, LDAP is the ideal choice. It is more effective and simple. This framework is applied to a large bank, the bank's systems can belong to different regions, and use of personnel may come from different geographies. In order to achieve distributed management, the use of three-level management, respectively named the Bank headquarter, Provincial and City branches of the three levels of branches, as shown in Fig 4:
Figure 4: LDAP Authentication Structure
Directory replication and directory reference is the most important technology in LDAP protocol. It can be seen from the figure, Provincial and City branches of the LDAP server branch data are copied from the floor, but not a simple copy of all information, just copy the relevant data with their own information. Because for a particular application system, its users are mostly belong to the sameregion, so that implementation can greatly simplify the
management of directory services and to improve the efficiency of information retrieval When a user outside the region to use this system, because of its user information in the region can not retrieve LDAP server, you need to other regions of the LDAP server to query, and therefore requires a way to use up the reference queries,first Provincial branches of the server search, without further reference to Bank headquarter of the server up until the search to the appropriate user information.
The management of the regionalCitybranch, using the LDAP directory replication
model of Single Master/Multi Slave. When a directory user queries the directory information, Master LDAP Server and Slave LDAP Server (Slave server can have more than one) can provide services to the directory,depending on the directory user makes a request to which the directory server. When the user requests the directory update directory information, in order to ensure the Master LDAP Server and Slave LDAP Server in the same directory information content, the need for replication of directory information, thisis achieved through the LDAP Replica server data synchronization.Using directory replication, when the directory number of users increases or the need to improve system performance, only simply add Slave LDAP server to the systemand then can immediatelyeffective in improving system performance,and the whole directory service system can have a good load balancing.
E.Permissions Web Server
Access Controltechnology began in the computer age of providing shared data. Previously, the way people use computers is mainly to submit the run-code written by user or run the user profile data. Users do not have much data sharing, and do not exist to control access to data. When computer comes into user's shared data, the subject of access control is nature to put on the desktop.Currently, the widely used access control models is using or reference to the early nineties of last century the rise of role-based access control model (Role-Based Access Control -RBAC). RBAC model's success is that it is inserted the "role" concept between the subject and object, decouples effectively between subject and the corresponding object (permission), and well adapts to the subject and object associated with the instability.RBAC model includes four basic elements, namely the user (User -U), roles (Roles -R), session (Session -S) and permission (Permission -P), also in the derived model also includes constraints (Constrains -C).The basic idea is to assign access rights to roles, and then the roles are assigned to users. In one session, users can gain the access rights through roles. The relationship between the elements:a user can have multiple roles, a role can be granted to multiple users; a role can have multiple permissions, a permission can be granted multiple roles;user can have multiple conversations, but a conversationis only to bind a user; a conversationcan have multiple roles, a role can share to multiple conversations at the same time; Constraints are that act on specific constraints on these relationships. As shown in Fig 5: