SSO single sign-on

1. SSO

requirements Single sign-on (Single Sign On, SSO) is the most common requirement in enterprise application integration. Heterogeneous systems often have their own user management and authentication mechanisms. In order to

prevent users from frequently entering user names and passwords when switching systems, it is necessary to implement single sign-on.
2. SSO principle

When it comes to the principle of SSO, we must first talk about the authentication principle of general Web applications. The main reason why Web authentication can become a problem lies in the statelessness of the HTTP protocol, which leads

to the independence of each HTTP request and response. The state of the application is a general requirement of most application systems, so other mechanisms must be used, which are cookies.
2.1. Principle of Cookie

A cookie consists of name, value, domain, path, and expires. You can add a cookie to the HTTP response, and then the cookie is

returned to the browser as the header of the HTTP response. For example, the Cookie response header after the successful login of Domino is:

Set-Cookie: DomAuthSessId=1AD479C4D11CD10278A4C523320A6918

; The current browser process is valid during the lifetime and will not be saved to the client; if the expires time is greater than the current time, the browser will write

the cookie to the client file after receiving it , usually stored in C:\Documents and Settings\Administrator\Cookies\.

If domain is not set, it means it is only valid in the current domain.

When the client requests other resources in the domain again, the browser will automatically attach the cookie in the domain to the request header and send it to the web server, such as:

Cookie: DomAuthSessId=1AD479C4D11CD10278A4C523320A6918 In

this way, the web application can read the HTTP request by The Cookie value in the header is used to determine the user's identity, which indirectly realizes

the .
2.2

. The principle of SSO It is not difficult to understand the principle of SSO after understanding the principle of Cookie. The purpose of SSO is to realize single sign-on between two or more application systems. The realization method is nothing more
than to automatically log in to B system, C system, etc. while logging in to A system. At the same time, go to system A, system B, and system C for verification, and return the cookie from each system to the browser. It's that simple.

In general, SSO requires a unified login interface, which can be achieved by redirecting the login interface of each application system to a designated login page.
2.3. Limitations of Cookies

If it is as simple as the above, it will not create the concept of SSO. The problem is with the cookie's domain. For browser security considerations, the cookie can take effect only when the domain of the cookie in the HTTP response header is the same as the HTTP request domain (a.abc.com) or the upper-level domain (abc.com).

That is to say:

if the domain names of systems A and B are a.abc.com and b.abc.com respectively, log in to system A, write cookies from both systems to the browser at the same time, and set the domain of the cookie to .abc.com , then the browser is acceptable and the SSO succeeds.

If the domain names of systems A and B are a.abc.com and b.xyz.com respectively, log in to system A, and write cookies from both systems to the browser at the same time. If the domain is set to .xyz.com, the browser cannot accept the B cookie, because the HTTP request is from .abc.com, so the cookie in the .xyz.com domain cannot be written.

This is the reason for the cross-domain SSO conundrum.
2.4. Cross-domain SSO

Knowing the limitations of cookies and the problem of cross-domain SSO, it is not difficult to find a solution to the cross-domain problem: each application system creates a cookie of its own domain and returns it to the browser. Don't fantasize about creating cookies for all domains in one app, it's futile.

As for how to create a cookie of each domain in each application system and return it to the browser at one time, this is a matter of opinion. The common practice is

to use JS script to dynamically create a hidden IFRAME in the return page of successful SSO verification. , and pass the verification information to a certain resource of each application system through the URL parameter of the SRC attribute of the IFRAME. These resources can be dynamic programs or JS scripts. to complete the verification process of the application and return the verified cookie.

The approach described below is slightly different from the above. My idea is that the authentication of which application system is only performed when which application system is requested, instead of verifying all the identities at one time.
3. Domino SSO implements

Domino's user information and authentication through the directory (NAMES.NSF); J2EE systems often have their own user management and authentication mechanisms. To achieve the SSO of the two, it can be done by deploying a unified authentication application.

There are three options for deploying a unique SSO application:

l Expand the identity authentication function of Domino to provide SSO service;

l Expand the identity authentication function of J2EE system to provide SSO service;

l Deploy a separate SSO application to provide SSO service;

Domino identity authentication is performed in names.nsf, and the login interface is in In domcfg.nsf, the authentication process can be completed by submitting a request containing the username (username) and password (password) to the path /names.nsf?Login. But Domino authentication is realized through its internal mechanism, and it does not provide developers with any displayed program code (code of how to verify user name and password), so it is impossible to directly extend the Domino authentication process.

The user management and identity authentication of the J2EE system itself are often designed by us, so it can be extended to achieve single sign-on on this basis, which is what we use here.

In addition, it is also possible to develop a separate SSO application to integrate the login process of Domino and J2EE systems, which is essentially the same as extending on the basis of J2EE systems, and will not be repeated here.
3.1. Domino Cookie

As mentioned earlier, the principle of SSO is Cookie, so it is necessary to understand the Cookie of Domino system.

The Domino system has two types of cookies to maintain session state according to the server configuration.


l Single server, the cookie name returned by the server to the browser is: DomAuthSessId.

l Multiple servers (SSO), the cookie name returned by the server to the browser is: LtpaToken, which is a set of lightweight third-party authentication standards from IBM that automatically supports SSO between Websphere and Lotus.
3.2. Domino system settings

1. Configure Domino's login page Open the domcfg.nsf database

with Notes, open the "Sign In Form Mapping" configuration document, and set the login page to the SSOLoginForm form in domcfg.nsf.


2. Redirect the Domino login page to J2EE

Open domcfg.nsf\SSOLoginForm with Designer and redirect it to the SSO login page by script:

js code


    <script language=”javascript”> 
    parent.location.href = “http:/ /www.j2ee.com/loginAction.do?method=login&redirectTo=<calculated text>”; 
    </script> 


where the calculated text is the value of RedirectTo, which records the DominoURL of the original user request.
3.3. J2EE system SSO development
3.3.1. SSO login interface

In the SSO login form, in addition to the necessary user name and password input boxes, there should be an attribute redirectTo to record the redirection path after login. When a user accesses a restricted resource, the system automatically redirects the user to the login interface and records the path of the restricted resource. When the user name and password are entered and the authentication is successful, the system automatically redirects the user to the restricted resource. , rather than simply returning to the default home page.
3.3.2. SSO Verification Procedure

The authentication of the J2EE system itself still has the traditional user name and password verification method. When checking that the access request from the client is to the Domino system, Domino's authentication will be done automatically and redirected to the corresponding Domino page. Automatic Domino verification is divided into two steps:

1. The program automatically accesses the Domino system from the server background through Http URLConnection and logs in. If the verification passes, the corresponding cookie value is read;

single-server form-based verification obtains the cookie and redirects the URL The code is as follows:
java code


    URL url = new URL(httpHost + "names.nsf?Login"); 
     
    HttpURLConnection.setFollowRedirects(false); 
     
    HttpURLConnection urlConnection = (HttpURLConnection) url.openConnection(); 
     
    urlConnection.setDoOutput(true); 
     
    OutputStreamWriter wr = new OutputStreamWriter(urlConnection.getOutputStream()); 
     
    wr.write("username=" + userName + "&password=" + password); 
     
    wr.flush(); 
     
    wr.close(); 
     
    urlConnection.connect(); 
     
    Map
     
    for (Iterator<string> it = headerFields.keySet().iterator(); it.hasNext(); ) {  </string>
     
    String key = it.next(); 
     
    if (key != null && key.equals(”Set-Cookie”)) { 
     
    String value = urlConnection.getHeaderField(key); 
     
    String[] cookies = value.split(”;\\s*”); 
     
    for (int i = 0; i < cookies.length; i++) { 
     
    String[] cookie = cookies[i].trim().split(”=”); 
     
    if (cookie[0].equals(”DomAuthSessId”)) { 
     
    successful = true; 
     
    loginURL = httpHost + “domcfg.nsf/SSOLoginAction?OpenAgent”; 
     
    loginURL += “&cookeName=DomAuthSessId”; 
     
    loginURL += “&cookeValue=” + cookie[1]; 
     
    break; 
     
    } 
     
    } 
     
    } 
     
    } 
     
    urlConnection.disconnect(); 


The multi-server (SSO) method to obtain cookies and redirect URL codes is as follows:
java code


    Session session = NotesFactory.createSession(serverName, userName, password); 
     
    if (session != null && session.isValid ()) { 
     
    successful = true; 
     
    loginURL = httpHost + “domcfg.nsf/SSOLoginAction?OpenAgent”; 
     
    loginURL += “&cookeName=LtpaToken”; 
     
    loginURL += “&cookeValue=” + URLEncoder.encode(session.getSessionToken(), “ UTF-8″); 
     
    } 


2. The program passes the acquired cookie name, cookie value and destination resource address to a Domino proxy (that is, the variable loginURL in the above code) through URL parameters, and the Domino proxy writes the cookie and repeats it. Directed to the destination resource address. The Domino proxy SSOLoginAction is also very simple, the code is as follows:
Domino code

    cookieName$ = request.GetParameter("cookeName") cookieValue 
     
    $ = request.GetParameter("cookeValue") 
     
    redirectTo$ = request.GetParameter("redirectTo") 
     
    Print {Set-Cookie:} + cookieName$ + {=} + cookieValue$ + {; path=/} 
     
    Print {Location: } + redirectTo$ + {} 


where request.GetParameter is a custom class method to get the parameter value in the URL.

In this way, the cross-domain SSO between J2EE and Domino systems can be successfully implemented in J2EE.