Can We Achieve Seamless Account Interoperability Across Multiple Company Systems?

Background

When a product portfolio expands, users must switch between systems, leading to poor user experience, increased password‑management overhead, and reduced overall security. Implementing single sign‑on (SSO) can improve usability and efficiency.

Traditional Session Mechanism and Authentication

HTTP is stateless, so servers create a session for each request and issue a JSESSIONID cookie. If cookies are disabled, URL rewriting passes the session ID. The server extracts the session ID, looks up the session data in an in‑memory hash table, or creates a new session.

Typical session handling steps:

Extract the session ID from the cookie.

Lookup the session data in storage.

If the session ID is missing, create a new session and return a JSESSIONID cookie.

Session Sharing in Clustered Environments

In a load‑balanced cluster, successive requests from the same user may be routed to different servers, making the original session unavailable. Two main approaches address this:

Session replication : each server copies session data to the others on login, update, or logout (high implementation cost, maintenance difficulty, and latency).

Centralized session storage : a dedicated service (commonly Redis) stores all session data, allowing any server to retrieve it and avoiding synchronization overhead.

Login Challenges in Multi‑Service Architecture and SSO Solution

Each system often has its own authentication mechanism, forcing users to log in repeatedly. A central authentication domain (e.g., ouath.com) can issue a ticket usable by all downstream services, eliminating repeated logins.

CAS‑Based Single Sign‑On Process

The CAS flow works as follows:

User accesses b.com, which redirects to ouath.com for login.

User submits credentials on ouath.com and receives a cookie scoped to ouath.com.

The session ID and user data are stored in Redis. b.com receives a ticket parameter, looks up the session ID in Redis, restores the session, sets its own cookie, and redirects the user back to the original page.

CAS Demo Code

Core Java classes used in the demo:

public class UserForm implements Serializable {
    private static final long serialVersionUID = 1L;
    private String username;
    private String password;
    private String backurl;
    // getters and setters omitted for brevity
}

@Controller
public class IndexController {
    @Autowired
    private RedisTemplate redisTemplate;

    @GetMapping("/toLogin")
    public String toLogin(Model model, HttpServletRequest request) {
        Object userInfo = request.getSession().getAttribute(LoginFilter.USER_INFO);
        if (userInfo != null) {
            String ticket = UUID.randomUUID().toString();
            redisTemplate.opsForValue().set(ticket, userInfo, 2, TimeUnit.SECONDS);
            return "redirect:" + request.getParameter("url") + "?ticket=" + ticket;
        }
        UserForm user = new UserForm();
        user.setUsername("laowang");
        user.setPassword("laowang");
        user.setBackurl(request.getParameter("url"));
        model.addAttribute("user", user);
        return "login";
    }
    // other handlers omitted for brevity
}

public class LoginFilter implements Filter {
    public static final String USER_INFO = "user";
    // doFilter checks session and redirects to /toLogin when unauthenticated
}

public class SSOFilter implements Filter {
    private RedisTemplate redisTemplate;
    public static final String USER_INFO = "user";
    // doFilter validates ticket, loads user from Redis, sets session, deletes ticket
}

CAS vs OAuth2

CAS (Central Authentication Service) is a web‑SSO framework that authenticates users and issues tickets for client applications. OAuth2 is an authorization protocol that allows third‑party clients to access resources on behalf of a user without exposing credentials. CAS focuses on protecting client‑side resources, while OAuth2 protects server‑side resources.

Use CAS when a unified username/password authentication is required across internal services; use OAuth2 when external services need delegated access to user resources.