Mastering Single Sign-On (SSO): Architecture, Implementation, and Performance Insights

Abstract: Single Sign-On (SSO) technology is increasingly applied to software systems across many domains. This paper analyzes SSO requirements from a business perspective, examines its internal mechanisms, and provides Web‑SSO and desktop SSO implementations with source code, while evaluating security, performance, risks, and integration strategies for architects.

Keywords: SSO, Java, J2EE, JAAS

1. What is Single Sign‑On

Single Sign‑On (SSO) allows a user to log in once and gain access to multiple trusted applications without re‑authenticating. Large enterprises often have dozens of heterogeneous systems (ERP, databases, operating systems, firewalls) that evolve independently, creating management overhead and data redundancy. Integrating authentication across these systems reduces operational cost and improves security.

2. Technical Mechanism of SSO

SSO works by issuing a secure ticket after the user authenticates with a central authentication service. Subsequent application requests carry this ticket; the application validates it with the authentication service (often via SAML or similar protocols). The ticket can be stored in a cookie, enabling seamless access across multiple applications, even when multiple authentication servers are deployed.

Key functions required:

All applications share a single authentication service that issues and validates tickets.

Applications must be able to extract and verify the ticket from incoming requests.

3. Web‑SSO Implementation

Web applications are stateless (HTTP), so SSO relies on cookies to maintain user state. After a successful login, the authentication service creates a cookie containing the ticket, sets its domain, path, and expiration, and redirects the user back to the originally requested URL.

3.1 Sample Web‑SSO Code (J2EE)

package DesktopSSO;
import java.io.*;
import java.net.*;
import java.text.*;
import java.util.*;
import java.util.concurrent.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class SSOAuth extends HttpServlet {
    static private ConcurrentMap accounts;
    static private ConcurrentMap SSOIDs;
    String cookiename="WangYuDesktopSSOID";
    String domainname;
    public void init(ServletConfig config) throws ServletException {
        super.init(config);
        domainname = config.getInitParameter("domainname");
        cookiename = config.getInitParameter("cookiename");
        SSOIDs = new ConcurrentHashMap();
        accounts = new ConcurrentHashMap();
        accounts.put("wangyu", "wangyu");
        accounts.put("paul", "paul");
        accounts.put("carol", "carol");
    }
    protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        PrintWriter out = response.getWriter();
        String action = request.getParameter("action");
        String result = "failed";
        if (action == null) {
            handlerFromLogin(request, response);
        } else if (action.equals("authcookie")) {
            String myCookie = request.getParameter("cookiename");
            if (myCookie != null) result = authCookie(myCookie);
            out.print(result);
            out.close();
        } else if (action.equals("authuser")) {
            result = authNameAndPasswd(request, response);
            out.print(result);
            out.close();
        } else if (action.equals("logout")) {
            String myCookie = request.getParameter("cookiename");
            logout(myCookie);
            out.close();
        }
    }
    // ... other methods omitted for brevity ...
}

3.2 Core Functions

handlerFromLogin()

validates username/password against the in‑memory accounts map, creates a unique ticket, stores the mapping in SSOIDs, sets a cookie, and redirects the user to the original URL.

The servlet also supports ticket validation ( authcookie), direct credential verification ( authuser), and logout.

4. Deployment Guide

Download the sample packages (SSOAuth, SSOWebDemo1, SSOWebDemo2) from the provided URLs, adjust web.xml init parameters ( SSOServiceURL, SSOLoginPage, domainname), package each application as a WAR, and deploy to any J2EE container supporting Servlet 2.3 or higher (Tomcat 5, JBoss 4, etc.). Ensure the demo applications share the same domain name so the cookie is visible to both.

After deployment, accessing the first demo redirects to the login page; after successful authentication, the second demo is accessed without another login, demonstrating true single sign‑on.

For desktop SSO, the same ticket mechanism is used, but the client is a native application that stores the ticket in a local cookie‑like store and presents it to web services when needed.

Overall, the article provides a complete overview of SSO concepts, practical Java/J2EE implementation, security considerations, and performance benefits such as reduced login time, lower help‑desk calls, and improved productivity.