The informatization process of an enterprise is a step-by-step process. During the gradual construction of various business websites of the enterprise, corresponding application systems are constructed according to the needs of various business information levels, because these application systems are generally developed in different periods. , Each application system has its own independent user library and user authentication system due to different functions, design methods and development techniques. With the continuous increase of new business websites, users have independent accounts in each application system, so that when accessing different application systems, the corresponding user names and passwords need to be recorded, and multiple user names and passwords are easy to remember. Mixed, if you forget or remember the user name or password of a certain business website, you will not be able to log in, delay work, and affect work efficiency. With the advancement of the informatization process within the bureau, new application systems will be created. For the user login solution, it is difficult for the company-wide staff names, especially the leaders at all levels to bear the approval authority, to remember the user names and passwords of various application systems, which seriously affects the speed and efficiency brought by informatization. In addition, multiple application platforms have multiple users to manage, which also brings huge workload to system administrators and maintainers. For example, if 10 personnel are changed at a time, even if there are only 5 application systems, 50 applications need to be repeatedly maintained. Personnel information, and each personnel adjustment of the enterprise is far less than 10 people. This geometric increase in maintenance workload will waste a lot of energy and time, and weaken the convenience brought by the information system. Therefore, it is necessary to establish a set of Unified, complete and scientific single sign-on system, each user only needs to record a user name and password, and after logging in to a platform, the transparent jump of each application system can be realized, and a unified user information management system is implemented, and system management Employees only need to maintain a set of personnel information, and the changed information is synchronously updated to each application system through the platform interface, so that the personnel system can be maintained synchronously and changed in the whole company at one time, which greatly improves the work efficiency.
The new application system is constantly being developed. The standard interface for single sign-on is planned and designed one day earlier, and an integrated standard can be proposed for the newly developed system. In the early stage of development, no matter which developer or technology is used, As long as the standard of single sign-on is followed, the new system can be seamlessly integrated into the single sign-on platform after the development of the new system is completed, thus reducing the waste of resources caused by changes to the single sign-on after system development is completed.
From the perspective of information sharing, each existing business system uses its own data storage method, and cannot transmit valid information to each other without basic user name and password authentication. In order to avoid the generation of information islands, it is necessary to establish a technical architecture and standards that connect various business systems to achieve unified platform integration; to achieve regulatory transparency through business processing and exception handling; to achieve business by separating business processes from applications The flexible arrangement of the process requires a set of information sharing platform that can integrate existing business websites.
The English name of single sign-on is Single Sign-On, abbreviated as SSO, which is a user authentication process that allows users to access different applications in the system after one-time authentication; Re-enter password. IBM has a vivid explanation of SSO "single sign-on, whole network roaming".
SSO centralizes user login and user account management in all domains within an enterprise. The benefits of SSO are obvious:
- Reduce the time it takes for users to log in in different systems, and reduce the possibility of user login errors
- Achieving security while avoiding processing and saving authentication information of multiple system users
- Reduced time for system administrators to add, delete users and modify user permissions
- Increased security: System administrators have a better way to manage users, including the ability to remove a user's access to all system resources by directly banning and deleting the user
For enterprises with multiple internal application systems, the effect of single sign-on is very obvious. Many international enterprises have taken single sign-on as one of the basic functions of system design.
Since the company's first version of the single sign-on system was launched in 2005, it has expanded from dozens of application systems to hundreds of systems now. In the process of application, the problem of cross-domain name, the use of single sign-on client code, and the access rules of the application system are not well solved.
The implementation mechanism of SSO is not the same, which can be roughly divided into two categories: Cookie mechanism and Session mechanism.
- WebLogic shares authentication information through Session. Session is a server-side mechanism. When the client accesses the server, the server creates a unique SessionID for the client to keep the state throughout the interaction process, and the interactive information can be specified by the application itself. Therefore, the session method is used. To implement SSO, single sign-on cannot be achieved between multiple browsers, but it can be cross-domain.
- WebSphere records authentication information through cookies. Cookie is a client-side mechanism. The content it stores mainly includes: name, value, expiration time, path and domain. The combination of the path and the domain constitutes the scope of the cookie. Therefore, SSO can be achieved by using the cookie method, but the domain name must be the same.
At present, most SSO products use the cookie mechanism, as does the company's first version of the single sign-on system. The best open source single sign-on product CAS can find so far also uses the cookie mechanism. CAS http://www.ja-sig.org/products/cas/ , the CAS single sign-on system was first developed by Yale University. In December 2004, CAS became a project within the JA-SIG. JA-SIG, whose full name is Java Architectures Special Interest Group, is an organization that promotes and discusses Java-based open source technologies in colleges and universities. CAS has many advantages, such as advanced design concept, reasonable architecture, simple configuration, extensive client support, mature technology and so on. This is also our reference product for this SSO transformation.
Taking CAS as an example, the schematic diagram of implementing single sign-on using cookies is shown in Figure 1.
- First, single sign-on is divided into "server" and "client". The server is the single sign-on server, and the client is usually a "library" or "plug-in". Applications that need to use single sign-on need to install the client plug-in into their system, or include the client function library in the code. Single sign-on clients typically replace the code in the authentication portion of the original application.
- An application must first initiate the first authentication. In most cases, the client embedded in the application will block the original login screen of the application and go directly to the login page of the single sign-on server.
Figure 1 Schematic diagram of using cookies to implement single sign-on
- The user enters a username and password on the login page of the single sign-on server.
- The single sign-on server then authenticates the username and password. Authentication itself is not a function of the single sign-on server, so some kind of authentication mechanism is usually introduced. There can be many authentication mechanisms, such as writing an authentication program by yourself, or using some standard authentication methods, such as LDAP or database, and so on. In most cases, LDAP is used for authentication. This is because LDAP has many unique advantages in handling user logins, which will be described in more detail later in this article.
- After the authentication is passed, the single sign-on server will perform a more complex interaction with the application, which is usually some kind of authorization mechanism. CAS uses what is called a Ticket. The specifics will be introduced later.
- After authorization is complete, CAS redirects the page back to the web application. The web application has completed a successful login at this time (of course, this is also a single sign-on client, and the success is judged according to the returned Ticket information).
- The single sign-on server then creates a cookie on the client side . Note that a cookie is created on the user's client, not the server. This cookie is an encrypted cookie that saves the user's login information.
- If the user wishes to enter other web applications at this time, the single sign-on client installed in these applications will still be redirected to the CAS server first. However, at this time, the CAS server no longer requires the user to enter the user name and password, but first automatically searches for the cookie, and logs in according to the information saved in the cookie. After login, CAS redirects back to the user's application.
This eliminates the need for the user to continue to enter a username and password, enabling single sign-on.
Note that in this single sign-on system, the password is not passed through http (but the user name is passed), so it is very secure.
CAS is designed as a stand-alone Web application and is currently implemented through several Java servlets. CAS must run on top of a web server that supports SSL. Applications can use CAS through three URL paths, namely the login URL (login URL), the verification URL (validation URL), and the logout URL (logout URL).
- At the beginning of the application, it usually skips the original login interface and directly turns to the login interface that comes with CAS. Of course, you can also add a button such as login on the main interface of the application to complete the jump work.
- If the user likes, he can also directly enter the login interface of CAS manually, log in first, and then start other applications. However, this mode is mainly used in test environments.
- The login interface of CAS handles what is called "principal authentication". It requires the user to enter a username and password just like a normal login screen.
- During principal authentication, CAS obtains the username and password, and then authenticates through some authentication mechanism. Usually the authentication mechanism is LDAP.
- For subsequent single sign-on, CAS sends a so-called "memory cookie" back to the browser. This cookie is not really stored in memory, but just expires automatically as soon as the browser is closed. This cookie is called the "ticket-granting cookie" and is used to indicate that the user has successfully logged in.
- After successful authentication, the CAS server creates a long, randomly generated string called "Ticket". Subsequently, CAS associates this ticket with the user who has successfully logged in, as well as the service. This ticket is a one-time-use credential, which is only used once for the user who has successfully logged in and its service. Immediately after use.
- After the subject authentication is completed, CAS redirects the user's browser back to the original application. The CAS client, when switching from the application to CAS, also records the original URL, so CAS knows who is calling itself. When CAS redirects, pass the ticket back as a parameter.
- For example, the URL of the original application is http://www.itil.com/, on this URL, there is the following statement at the beginning, going to the single sign-on page of the CAS server https://secure.oa.com/cas/login? service=http://www.itil.com/auth.aspx.
- After CAS completes the subject authentication, it will use the following URL to redirect http://www.itil.com/authenticate.aspx?ticket= ST-2-7FahVdQ0rYdQxHFBIkKgfYCrcoSHRTsFZ2w-20.
- After receiving the ticket, the application needs to validate the ticket. This is accomplished by passing the ticket to a validation URL. The verification URL is also provided by the CAS server.
- After CAS obtains the ticket through the verification path, it judges it through the internal database. If the judgment is validity, a NetID is returned to the application.
- CAS then invalidates the ticket and leaves a cookie on the client side.
- In the future, other applications will use this cookie for authentication (of course through the CAS client) without entering a username and password.
Using .NET to realize the SSO system of the CAS principle, some problems are listed on the basis of the first version of the SSO system, and some of them are already adopted in the first version of the SSO system. Some issues need to be clarified,
When many people talk about single sign-on, they are often confused with unified users and single-user management. Either they mistakenly think that single-sign-on naturally realizes single-user management; In fact, these three concepts are clearly differentiated.
Unified user refers to different systems that use the same set of user processing mechanisms.
- User IDs are globally unique, user login names, and passwords are globally unique, and are stored uniformly in a single system.
- Some attributes of users, such as name, phone number, address, email, etc., are uniformly stored in a single system. Although each application system can add some attributes by itself, the basic attributes should be stored and managed uniformly.
- The application system should not directly add, modify or delete user information, but it can be queried. The addition, modification and deletion of user information should be managed uniformly by a special system.
Obviously, unified user is the basis of single sign-on, but unified user does not mean that single sign-on is realized .
Single user management means that all user management work is handled in a single place, and each application no longer retains its own user management functions. The biggest difference between single user management and unified user management is that after unified user management, each application still retains its own user management functions for additional attribute settings; while under single user management, each application no longer retains its own user management functions. user management function.
In the enterprise application scenario, all user information comes from the HR system, and the user information and department information contained in the HR system will exist in the company's active directory. The company uses a combination of LDAP and database connection. Official employees log in to the OA system without using LDAP authentication, but using RSA token authentication, which is database authentication. For external employees who forgot to bring a token card and the customer service department does not have a token card, they are allowed to authenticate through LDAP through a whitelist. The first version of the single sign-on system used HTTP, and the new version of the integration subsystem used https for communication.
Terminology Explanation:
- HTTPS (full name: Hypertext Transfer Protocol over Secure Socket Layer) is a secure HTTP channel, in short, a secure version of HTTP. That is, the SSL layer is added under HTTP, and the security foundation of HTTPS is SSL. Therefore, please refer to SSL for details of encryption. It is a URI scheme (abstract identifier scheme) with a syntax similar to the http: scheme. For secure HTTP data transfer. The https: URL indicates that it uses HTTP, but HTTPS has a different default port than HTTP and an encryption/authentication layer (between HTTP and TCP). Originally developed by Netscape, the system provides a method of authenticating and encrypting communications, and is now widely used for secure-sensitive communications on the World Wide Web.
- LDAP (the full name is Lightweight Directory Access Protocol), generally referred to as LDAP. It is based on the X.500 standard, but is much simpler and can be customized as needed. Unlike X.500, LDAP supports TCP/IP, which is necessary to access the Internet. The core specifications of LDAP are defined in RFCs, and all LDAP-related RFCs can be found on the LDAPman RFC webpage.
Simply put, LDAP is a fast way to get centralized, static data about people or resources. The LDAP protocol is cross-platform and standard, so applications don't have to worry about what server the LDAP directory is placed on. In fact, LDAP is widely recognized by the industry because it is the standard of the Internet. Manufacturers are very willing to add support for LDAP in their products, because they don't have to think about what the other side (client or server) is. The LDAP server can be any open source or commercial LDAP directory server (or possibly a relational database with an LDAP interface) because the same protocol, client connection package, and query commands can be used to interact with the LDAP server.
Source: http://shanyou.cnblogs.com/
Copyright: The copyright of this article belongs to the author and the blog Park
Reprint : Welcome to reprint, in order to preserve the author's creative enthusiasm, please follow the requirements [reprint] ], thank you
Requirements : This statement must be retained without the author's consent; the original link must be given in the article; otherwise, legal responsibility must be held