Write your own Single Sign-On (SSO) Service-1

Http://chinesedocument.com/html/jishuxueyuan/J2SE/Javahexin/20070515/3799.html 1 What is single sign-on

Single Sign On (SSO) is one of the most popular solutions for enterprise business integration. SSO is defined in multiple application systems. Users only need to log on once to access all mutually trusted application systems.

Within a large enterprise, many business support systems provide corresponding management and IT services. For example, the financial system provides financial management, computing and report services for financial personnel; the personnel system provides maintenance services for personnel departments throughout the company; various business systems provide different services for different internal businesses of the company. These systems aim to allow computers to carry out complex and complex computing tasks, replace manual labor, and improve work efficiency and quality. These different systems are often built in different periods and run on different platforms. They may be developed by different vendors and use different technologies and standards. For example, a famous IT company in China (with its name hidden) has over 60 internal business systems, including two different versions of sap erp systems, 12 database systems of different types and versions, 8 operating systems of different types and versions, and 3 different firewall technologies, there are dozens of mutually incompatible protocols and standards. Do you believe this? Do not doubt that this situation is very common. After several years of operation, each application system will become part of an irreplaceable enterprise IT architecture, as shown in.

With the development of enterprises, the number of business systems is constantly increasing, but old systems cannot be easily replaced, which brings a lot of overhead. One is management overhead, and more systems need to be maintained. Data in many systems is redundant and repetitive. data inconsistency puts a lot of pressure on management. The correlation between business and business is also growing. For example, there is an inevitable close relationship between the company's billing system, financial system, and personnel system.

To reduce the consumption of management and maximize the reuse of existing investment systems, many enterprises are carrying out enterprise application integration (EAI ). Enterprise Application Integration can be performed at different levels: for example, "data centralization" at the data storage level and "General Data Exchange Platform" at the transmission level ", "Business Process Integration" on the application layer and "General Enterprise Portal" on the user interface. In fact, integration at one level becomes more and more important, that is, integration of "Identity Authentication", that is, "Single Sign-On ".

Generally, each individual system has its own security system and Identity Authentication System. Before integration, login is required for every system. This situation not only brings great difficulties to management, but also poses a major security risk. The following are statistics from some famous companies:

• Average users per day16Minutes spent on authentication tasks-Source:IDS

• FrequentItAverage Users21Password (s)-Source:NTA monitor password Survey

• 49%The person wrote down his password, and67%People rarely change them.

• Each79An identity theft event occurs in seconds.-Source:National Small Business Travel assoc

• About annual global spoofing losses12b-Source:Comm fraud control assoc

• To2007The identity management market will multiply$ 4.5b-Source:IDS

After the "Single Sign-On" integration, you only need to log on to multiple systems at a time, instead of logging on again. This not only brings a better user experience, more importantly, it reduces security risks and management consumption. See the following statistics:

• ImproveItEfficiency: for each1000Managed users, saving per user$70 K

• Help station call should be reduced at least1/3,10 KThe company of employees can save every user every year$75, Or total$648 K

• Productivity Improvement: each new employee can save money$1 K, Saving for every old employee$350Source:Giga

• ROIReturn:7.5To13MonthsSource:Gartner

In addition, the use of "single sign-on" is still one of the needs of the SOA era. In a service-oriented architecture, communication between services and programs exists in large quantities. Security authentication between services is one of the difficulties in SOA applications, therefore, the establishment of a "single sign-on" system can greatly simplify SOA security issues and improve the cooperation efficiency between services.

 

2. Technical Implementation Mechanism of single-point Login

With the popularity of SSO technology, SSO products are also full of sky. All famous software vendors provide corresponding solutions. Here, I don't want to introduce my own company (Sun Microsystems) products. Instead, I want to parse the SSO technology itself and provide my own methods and simple demos for developing such products. For the purpose of writing this article, refer to my blog (Http://yuwang881.blog.sohu.com/3184816.html).

The Single Sign-on mechanism is actually relatively simple. It is compared with a real-world example. The Summer Palace is a famous tourist attraction in Beijing and a frequent place to visit. There are many independent scenic spots inside the Summer Palace, such as "Suzhou Street", "Buddha Pavilion", and "desheng", you can buy tickets separately at the entrance of each scenic spot. Many tourists need to visit all German attractions. This method of buying tickets is inconvenient. They need to queue up at the door of each attraction to buy tickets. The wallet is easy to lose and unsafe. Therefore, the vast majority of tourists choose to buy a pass (also called a pass) at the gate, they can play all the scenic spots without buying a new ticket. They only need to show the set of tickets they just bought at the door of each scenic spot to be allowed to access each independent scenic spot.

The Single Sign-on mechanism is also the same, as shown in, when a user accesses Application System 1 for the first time, because the user has not logged on, it will be directed to the authentication system for login (1 ); based on the login information provided by the user, the authentication system performs identity verification. If the authentication is successful, a creden named ticket (2) should be returned to the user ); when you access another application (3, 5), the ticket is carried as the credential for authentication. After the application system receives the request, the ticket is sent to the authentication system for verification, check ticket validity ). After verification, you can access application system 2 and Application System 3 without having to log on again.

 

From the above view, we can see that to implement SSO, the following main functions are required:

• All application systems share an Identity Authentication System.
  A unified authentication system is one of the prerequisites for SSO. The main function of the authentication system is to compare the user login information with the user information library to authenticate the user login. After the authentication is successful, the authentication system should generate a unified authentication mark (Ticket ), return to the user. In addition, the authentication system should verify ticket to determine its validity.

• All application systems can identify and extract ticket information.
  To implement the SSO function and allow users to log on only once, the application system must be able to identify users who have logged on. The application system should be able to identify and extract ticket. by communicating with the authentication system, the system can automatically determine whether the current user has logged on to the system to complete the single-point logon function.

The above functions are just a very simple SSO architecture. In actual situations, SSO has a more complex structure. There are two points to note:

• A single user information database is not necessary. Many systems cannot store all user information in a centralized manner. User information should be stored in different storage systems, as shown in. In fact, as long as the unified authentication system and ticket are generated and verified, single-point logon can be achieved no matter where the user information is stored.

• A unified authentication system does not mean that there is only one authentication server. As shown in, the entire system can have more than two Authentication servers, and these servers can even be different products. Authentication servers must exchange authentication information through standard communication protocols to complete high-level single-point logon. For example, when a user accesses Application System 1, the first authentication server authenticates and obtains the ticket generated by the server. When he accesses Application System 4, Authentication Server 2 can identify that this ticket is generated by the first server and pass the standard communication protocol (such as SAML) between Authentication servers) to exchange authentication information.

3 realization of WEB-SSO

With the rapid development of the Internet, web applications almost dominated the vast majority of software application systems, so WEB-SSO is the most popular SSO application. WEB-SSO has its own characteristics and advantages, to achieve relatively simple and easy to use. Many commercial software and open-source software have the realization of WEB-SSO. It is worth mentioning that opensso (Https://opensso.dev.java.netTo provide the architecture guide and Service Guide for the Implementation of WEB-SSO with Java, and provide the theoretical basis and implementation method for the user to realize the WEB-SSO.

Why is WEB-SSO easier? This is determined by the characteristics of Web applications.

As we all know, the Web protocol (HTTP) is a stateless protocol. A Web application consists of multiple web pages, each of which is defined by a unique URL. The user enters the URL of the page in the address bar of the browser, and the browser sends a request to the web server. For example, the browser sends two requests to the Web server and applies for two pages. The two page requests use two separate HTTP connections. The so-called stateless protocol is shown here. the browser and the web server will close the connection channel after the first request is completed, and re-establish the connection at the second request. The Web server does not distinguish the client from which the request comes from. All requests are connected separately. This method is much different from the traditional (Client/Server) C/S structure. In such an application, the client and server will establish a dedicated connection channel for a long time. It is precisely because of stateless features that each connection resource can be quickly reused by other clients that a Web server can serve thousands of clients at the same time.

However, our common applications are stateful. You do not need to mention SSO between different applications. In the same application, you also need to save your login identity information. For example, the user logged on when accessing page 1, but as mentioned earlier, each client request is a separate connection. When the customer accesses page 2 again, how can I tell the web server that the customer has logged on just now? There is an agreement between the browser and the server: The Cookie technology is used to maintain the application status. Cookie is a string that can be set by the Web server and can be saved in the browser. As shown in, when the browser accesses page 1, the web server sets a cookie and returns the cookie together with page 1 to the browser. After the browser receives the cookie, it will save it, when it accesses page 2, it will also bring this cookie. When the Web server receives a request, it can also read the cookie value, you can determine and restore the Information Status of some users based on the content of the cookie value.

Web-Sso can use cookies to save user login information, and combine the cookies in the browser with the ticket mentioned above to complete the SSO function.

To complete a simple SSO function, we need to work with the following two parts:

1. Uniform Identity Authentication Service.

2. Modify the web application so that each application performs identity verification through this unified authentication service.

3.1 example of Web SSO

Based on the above principle, I used J2EE technology (JSP and Servlet) to complete a simple example with web-Sso. The sample contains an authentication server and two simple web applications, so that the two web applications can complete the web-Sso function through the Uniform Identity Authentication Service. In this example, all source code and binary code can be downloaded from this website.

Sample download, installation, deployment, and operation guide:

• The web-Sso sample consists of three standard web applications, which are compressed into three ZIP files and downloaded from this website. Ssoauth (Http: // 211.151.94.21/blog/yutoujava/resource/ssoauth.zip) Is the Identity Authentication Service; ssowebdemo1 (Http: // 211.151.94.21/blog/yutoujava/resource/ssowebdemo1.zip) And ssowebdemo2 (Http: // 211.151.94.21/blog/yutoujava/resource/ssowebdemo2.zipIs two web applications used to demonstrate Single Sign-On. The reason why these three web applications are not packaged into war packages is that they cannot be directly deployed and must be modified according to the deployment environment of the readers. The deployment and running environment of the sample has certain requirements and must comply with the above standards of servlet2.3 J2EE containers to run (such as Tomcat 5, Sun Application Server 8, JBoss 4, etc ). In addition, the identity authentication service requires the jdk1.5 runtime environment. Jdk1.5 is used because the author uses a high-performance Java Collection class "concurrentmap" with thread-safe performance, which is only available in jdk1.5.

• The three web applications can be deployed separately. They can be deployed on different machines, different operating systems, and different J2EE products, they are completely standard and platform-independent applications. However, there is a limitation that the domain names of the two demo1 and demo2 servers must be the same, this explains the relationship between cookies and domains and how to create a cross-domain WEB-SSO later.

• Decompress the ssoauth.zip file, in the/WEB-INF/web. modify the "domainname" attribute in XML to reflect the actual application deployment. The domainname must be set to the domain name of the two single sign-on applications (demo1 and demo2. This domainname is irrelevant to the domain name of the machine currently deployed by the ssoauth service. My default setting is ".sun.com ". If the demo1 and demo2 machines do not have a domain name, enter an IP address or host name (for example, localhost). However, if you use an IP address or host name, demo1 and demo2 must be deployed on one machine. After setting, you may need to compress the ssoauth Directory into a war File Based on the selected J2EE container. You can use "jar-CVF ssoauth. War ssoauth/" to complete this function.

• Decompress the ssowebdemo1 and ssowebdemo2 files and find the Web. xml file under them/WEB-INF/. modify several of the initialization parameters.
  <Init-param>
  <Param-Name> ssoserviceurl </param-Name>
  <Param-value>Http://wangyu.prc.sun.com: 8080/ssoauth</Param-value>
  </Init-param>
  <Init-param>
  <Param-Name> ssologinpage </param-Name>
  <Param-value>Http://wangyu.prc.sun.com: 8080/ssoauth/login. jsp</Param-value>
  </Init-param>
  Modify the ssoserviceurl and ssologinpage to the machine name, port number, and root path (ssoauth by default) of the ssoauth application to reflect the actual deployment. After the setting, you may need to compress the two directories ssowebdemo1 and ssowebdemo2 into two war files based on the selected J2EE container. You can use "jar-CVF ssowebdemo1.war ssowebdemo1/" to complete this function.

• Enter the test URL (test. jsp) for the first web application, such as http://wangyu.prc.sun.com: 8080/ssowebdemo1/test. jsp. If it is the first access, it will automatically jump to the login interface, as shown in

• Use one of the three accounts that comes with the system to log on (for example, Username: WangYu, password: WangYu). You can see the content of test. jsp: displays the current username and welcome information.
  

• Enter the test URL (test. jsp) of the second web application in the same browser, for example, http://wangyu.prc.sun.com: 8080/ssowebdemo2/test. jsp. You will find that you can see test without logging on again. JSP content also displays the current user name and welcome information, and the welcome information clearly shows the current application name (demo2 ).