Write your own single sign-on (SSO) Service-1

Original: http://chinesedocument.com/html/jishuxueyuan/J2SE/Javahexin/20070515/3799.html 1 What is a single point of landing

Single sign-on (Sign on), referred to as SSO, is one of the more popular solutions for enterprise business integration. SSO is defined in multiple application systems where users can access all trusted applications with only one login.

Within the larger enterprise, there are generally a number of business support systems to provide the appropriate management and IT services. For example, the financial system provides financial management, calculation and Reporting Services for the financial personnel, and the personnel system provides the personnel department with the maintenance service of the whole company; the various business systems provide different services for different businesses within the company. The purpose of these systems is to allow computers to carry out complex and tedious computational work to replace manual labor and improve efficiency and quality. These different systems are often built at different times, run on different platforms, and may be developed by different vendors, using a variety of technologies and standards. If, for example, a well-known IT company in China (name hidden), there are more than 60 business systems internally, including two different versions of SAP ERP systems, 12 different types and versions of database systems, 8 different types and versions of operating systems, and 3 different firewall technologies. There are dozens of different protocols and standards that are incompatible with one another, do you believe it? Do not doubt that this is a very common situation. Each application system, after several years of operation, becomes part of an irreplaceable enterprise IT architecture, as shown in the following illustration.

With the development of enterprises, the number of business systems is constantly increasing, the old system can not be easily replaced, which will bring a lot of overhead. One is the overhead of management, and more and more systems need to be maintained. The data of many systems are redundant and repetitive, and the inconsistency of data will put great pressure on the management work. The correlation between business and business is also increasing, such as the company's billing system and financial system, financial systems and personnel systems are inevitably closely related.

In order to reduce management consumption and maximize the reuse of existing investment systems, many enterprises are undertaking enterprise application integration (EAI). Enterprise application integration can be done at different levels: for example, "Data centralization" at the data storage level, "Common data exchange Platform" at the transport level, "business process integration" at the application level, and "General Enterprise Portal" on the user interface, etc. In fact, a level of integration is becoming more and more important, that is, "Identity authentication" integration, that is, "single sign-on."

In general, each individual system has its own security system and identity authentication system. Integration before, into each system need to log in, such a situation not only brought great difficulties in management, in the security has also buried a major hidden dangers. The following are some of the most notable statistics displayed by the survey companies:

Users spend an average of minutes per day on the authentication task - Source: IDS

Frequent IT users have a password on average - Source: NTA Monitor Password Survey

49% people write down their passwords, and 67% rarely change them.

An identity theft event occurs per second - Source: National Small Business Travel ASSOC

Global fraud loss of about 12B per year-source: Comm Fraud Control ASSOC

By 2007 year, the identity management market will grow exponentially to $4.5b- Source: IDS

With single sign-on integration, you can access multiple systems only once, without having to log on again, which not only brings a better user experience, but also lowers the risk of security and the cost of management. Take a look at the following statistical data:

Improve IT efficiency: For each 1000 user, each user can save $70k

Helpdesk calls are reduced by at least 1/3, and for 10K employees The company can save $75per user each year, or total $648k

Productivity gains: Each new employee can save $1k, and each old employee can save $350 sources: Giga

ROI return:7.5 to month data source: Gartner

In addition, the use of "single sign-on" is one of the requirements of the SOA era. In a service-oriented architecture, where there is a large number of communication between programs and programs, and security authentication between services is one of the difficulties of SOA applications, the establishment of a "single sign-on" system can greatly simplify the security issues of SOA and improve the efficiency of service cooperation.

2 technology Implementation mechanism of single point landing

With the popularity of SSO technology, SSO products are also flying in the sky. All the famous software vendors provide the corresponding solutions. Here I don't want to introduce my own company (Sun Microsystems) products, but to the SSO technology itself, and provide their own development of this type of product methods and a simple demonstration. For the purpose of my writing this article, please refer to my blog (http://yuwang881.blog.sohu.com/3184816.html).

Single sign-on mechanism is actually relatively simple, with a real example to do comparison. The Summer Palace is a famous tourist attraction in Beijing and a place I often visit. There are many independent attractions inside the Summer Palace, such as "Suzhou Street", "Buddhist Incense" and "Germany and garden", can buy tickets separately at the entrance of each scenic spot. Many tourists need to play all the German attractions, this way of buying tickets is very inconvenient, need to queue at the gate of each scenic spot to buy tickets, wallet brought in to take out, easy to lose, very unsafe. So the vast majority of tourists choose to buy a pass (also called package) at the gate, you can play all the sights without the need to buy a new ticket. All they need to do is show up at the gate of each attraction and be allowed to enter each individual attraction.

Single sign-on mechanism is the same, as shown in the following figure, when the user first access to the application System 1, because there is no login, will be guided to the authentication system for login (1); According to the user's login information, authentication system for the identity of the effectiveness, if through the effectiveness, Should return to the user a certified credential--ticket (2), the user will visit another application (3,5) on the ticket, as the credentials of their own authentication, application system to accept the request will be ticket sent to the certification system for efficacy, Check the legality of the ticket (4,6). With effectiveness, users can access application 2 and application System 3 without having to log in again.

As you can see from the above view, to achieve SSO, you need the following main features:

All application systems share an identity authentication system.
The unified authentication system is one of the prerequisites of SSO. The main function of the authentication system is to compare the user's login information with the user database, to authenticate the user, and the authentication system should generate a unified authentication mark (ticket) and return it to the user. In addition, the authentication system should also perform the ticket to judge its validity.

All application systems can identify and extract ticket information
To enable SSO to function so that users can log on only once, the application system must be able to identify the users who have logged in. The application system should be able to identify and extract the ticket, through the communication with the authentication system, can automatically determine whether the current user has logged in, thus completing the function of single sign-on.

The above functionality is just a very simple SSO architecture, and in reality the SSO has a more complex structure. There are two points to be noted:

A single user information database is not required, and many systems do not store all of the user information centrally, and should allow user information to be placed in different storage, as shown in the following illustration. In fact, as long as the unified authentication system, unified ticket generation and effectiveness, no matter where the user information stored, can achieve a single sign-on.

Unified authentication system does not say that only a single authentication server, as shown in the following figure, the entire system can exist more than two authentication servers, these servers can even be different products. Authentication server to pass the standard communication protocol, Exchange authentication information, can complete a higher level of single sign-on. The following figure, when the user accesses the application System 1 o'clock, by the first authentication server authentication, obtains the ticket which this server produces. When he accessed application 4, authentication server 2 recognized that the ticket was generated by the first server, exchanging authentication information through standard communication protocols (such as SAML) between authentication servers, and still being able to perform the SSO function.

3 Implementation of Web-sso

With the rapid development of the Internet, Web applications dominate most of the software applications, so Web-sso is the most popular SSO application. Web-sso has its own characteristics and advantages, to achieve a relatively simple and easy to use. Many commercial software and open source software have the realization of Web-sso. One worth mentioning is Opensso (https://opensso.dev.java.net), which provides architectural guidance and service guidance for Java implementation Web-sso, It provides the theory basis and the realization method for the user to realize Web-sso.

Why is Web-sso easier to achieve? This is determined by the characteristics of the Web application itself.

As we all know, Web protocol (that is, HTTP) is a stateless protocol. A Web application consists of a number of web pages, each of which has a unique URL to define. The user enters the URL of the page in the browser's address bar, and the browser sends the request to the Web server. In the following illustration, the browser sends two requests to the Web server and requests two pages. The requests for these two pages are to use two separate HTTP connections respectively. The so-called stateless protocol is where the browser and Web server close the connection channel after the first request completes and re-establish the connection at the second request. The Web server does not differentiate between which requests are from which client, and all requests are treated in a separate connection. This way is greatly different from the traditional (Client/server) C/S structure, in which applications, the client and server side will establish a long time dedicated connection channel. Because of the stateless nature, each connection resource can be reused by other clients quickly, and a Web server can serve thousands of clients at the same time.

But our usual applications are stateful. Without having to mention SSO between different applications, the user's logon identity information needs to be saved in the same application. For example, users visit the page 1 when the login, but also mentioned that the client's each request is a separate connection, when the customer again visit the page 2, how to tell the Web server, the customer has just logged in. There is a convention between the browser and the server: the use of cookie technology to maintain the state of the application. A cookie is a string that can be set by a Web server and can be saved in a browser. As the following illustration shows, when the browser accesses page 1 o'clock, the Web server sets a cookie and returns the cookie and page 11 to the browser, which is saved after the browser receives the cookie, and takes the cookie when it accesses page 2. The Web server can also read the value of the cookie when requested, and can judge and restore the information status of some users according to the contents of the cookie value.

Web-sso can completely use the cookie end to save the user login information, combine the cookie in the browser and the ticket in the above to complete the functions of SSO.

In order to complete a simple SSO function, two parts of the collaboration are required:

A unified identity authentication service.

Modify Web applications so that each application is authenticated through this unified authentication service. examples of 3.1 Web SSO

Based on the above principle, I used the Java technology (JSP and servlet) to complete a simple sample with Web-sso. The sample contains an authenticated server and two simple Web applications that enable the two Web applications to perform Web-sso functions through a unified identity authentication service. All source code and binaries for this sample can be downloaded from this web site.

sample Download, install Deployment and run Guide:

The Web-sso sample is made up of three standard web applications, compressed into three zip files and downloaded from this web site. where 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.zip) is a two Web application for demonstrating single sign-on. These three web applications are not made into war packages because they cannot be deployed directly, and a small change is needed to make a user's deployment environment. The sample deployment and operation environment has certain requirements, need to meet Servlet2.3 above standard Java container to run (such as Tomcat5,sun application Server 8, Jboss 4, etc.). In addition, the identity authentication Service requires a JDK1.5 operating environment. The reason to use JDK1.5 is because the author uses a thread-safe, High-performance Java Collection Class "Concurrentmap", only in JDK1.5.

These three web applications can be deployed individually, and they can be deployed separately on different machines, different operating systems, and different Java EE products, and they are entirely standard platform-independent applications. However, there is a limitation that the domain names of the two deployed applications (DEMO1, DEMO2) need to be the same, which in later chapters will explain the relationship between cookie and domain and how to make Cross-domain Web-sso

Extract the Ssoauth.zip file, and in the Web.xml under/web-inf/, modify the properties of the "DomainName" to reflect the actual deployment of the application. DomainName needs to be set to the domain name that the two single sign-on applications (Demo1 and Demo2) belong to. This domainname is not related to the domain name of the machine that the current Ssoauth service deploys. My default setting is ". Sun.com". If you deploy DEMO1 and Demo2 machines without domain names, enter the IP address or hostname (such as localhost), but using an IP address or hostname means that demo1 and demo2 need to be deployed to a single machine. After Setup, depending on the Java container you choose, you may want to compress the Ssoauth directory into a war file. Use "JAR-CVF Ssoauth.war ssoauth/" to complete this function.

Extract SSOWebDemo1 and SSOWebDemo2 files, locate web.xml files under their/web-inf/, and modify several of the initialization parameters
<init-param>
<param-name>SSOServiceURL</param-name>
<param-value>Http://wangyu.prc.sun.com:8080/SSOAuth/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 into the machine name, port number, and root path (by default, Ssoauth) to deploy the Ssoauth application to reflect the actual deployment. After Setup, depending on the Java container you choose, you may need to package the SSOWebDemo1 and SSOWebDemo2 directory compression into two war files. Use "JAR-CVF Ssowebdemo1.war ssowebdemo1/" to complete this function.

Please enter the test URL (test.jsp) for the first Web application, such as http://wangyu.prc.sun.com:8080/SSOWebDemo1/test.jsp, which will automatically jump to the login interface if it is first accessed, as shown in the following figure

Log in with one of the three accounts (for example, username: Wangyu, Password: Wangyu), and you will be able to successfully see the test.jsp content: Display the current username and welcome information.