For any company with more than one product, single sign-on is a problem. As front-end programmers, we don’t know much about it, but we need to understand it properly. This article will talk about single sign-on related issues.

Front knowledge

To understand SSO, the following is a good knowledge. Of course, if not particularly familiar, also does not affect reading.

  • The cookie and session
  • Browser same-origin policy and cross-domain
  • Understand the composition of the login system

What is SSO and CAS?

SSO

SSO is short for Single Sign On, which translates as Single sign-on. As the name implies, it extracts the logics of user login from two or more products to achieve the effect of logging in to multiple products at the same time only by entering the user name and password once.

SSO, for example, is a lot like the pass we buy when we go to Disney.

Instead of buying a new ticket at the roller coaster or ferris wheel, we can enjoy all the amusement park facilities by buying a single pass. Here, buying tickets is equivalent to login authentication, the amusement park is equivalent to the company using one SSO, and the various rides are equivalent to the company’s various products.



The advantages of using SSO are obvious:

  • Improve user experience.


  • Avoid duplication of development


  • Enhanced safety factor

If you are the operation and maintenance of our factory, you have found a hidden danger that needs urgent repair. Surely you can’t stand the idea of sending an email to the back end of so many products ordering them to be fixed? What if you miss one?

Taken together, SSO is not only useful, but necessary.

CAS

SSO is simply an architecture, a design, and CAS is a means to achieve SSO. Both are abstract and concrete. Of course, there are other ways to implement SSO besides CAS, such as simple cookies.

The Central Authentication Service (CAS) is an open source protocol, with versions 1.0 and 2.0. 1.0, called base mode, and 2.0, called proxy mode, are suitable for single sign-on between non-Web applications. This article deals only with CAS 1.0, which is covered in more detail below.

Evolution and classification of SSO

Here’s a closer look at SSO in various scenarios that escalate and complicate the relationship.

1. With domain SSO

As shown, co-domain SSO is the simplest case.

At this point, both products are under the same domain name, so single sign-on is a natural choice. Let’s go through the steps. Make sure that these steps are the basis for understanding the rest of the text. Don’t skip them.

  1. The user accesses product A and sends a login request to the background server.
  2. After the login authentication succeeds, the server writes the user login information into the session.
  3. The server generates a cookie for the user and adds it to the Response header, which is written to the browser as the request is returned. The cookie’s field is set to ddxy.cn.
  4. Next time, when a user accesses product B with the same domain name, the browser will automatically bring the previous cookie because A and B are under the same domain name, which is also ddxy. cn. At this point, the background server can verify the login status through the cookie.

In fact, this scenario is the simplest and most traditional login operation. Although we artificially separate products A and B, since they are in the same domain, it is ok to consider them as different categories of the same product. We did not set up a separate SSO server because the business backend server itself was sufficient to assume SSO functions.



2. SSO in the parent domain

SSO in the same parent domain is a simple upgrade of SSO in the same domain. The only difference is that when the server returns a cookie, the domain of the cookie is set to the parent domain.

For example, if the IP addresses of two products are respectively A.dexy.cn and b.dexy.cn, the cookie domain should be dexy.cn. This cookie can be sent to the server when accessing both A and B, essentially the same as same-domain SSO.

3. The cross-domain SSO

As you can see, in neither case did we specifically set up an SSO server. However, cookies cannot be shared when the two products are in different domains, so we must set up separate SSO servers. At this point, we implement SSO through a standard CAS scheme. Here we will introduce it in detail:


Rounding out the CAS

The CAS 1.0 protocol defines a set of terms, a set of tickets, and a set of interfaces.


Terms:

  • Client: indicates a user.
  • Server: The central Server that is also responsible for single sign-on in SSO.
  • Service: Services that require single sign-on, equivalent to product A/B above.

Interface:

  • /login: login interface for logging in to the central server.
  • /logout: logout interface used to logout from the central server.
  • /validate: verifies whether the user has logged in to the central server.
  • /serviceValidate: Used to allow individual services to verify that a user is logged into the central server.

paper

  • TGT: Ticket Grangting Ticket

A TGT is a login ticket issued by CAS for users. With a TGT, users can prove that they have successfully logged in to CAS. The TGT encapsulates the Cookie value and the user information corresponding to this Cookie value. When an HTTP request arrives, CAS queries the cache for TGTS based on the Cookie value (TGC). If there is a TGT, CAS believes that the user has logged in.


  • TGC: Ticket Granting Cookie


  • ST: the Service Ticket

An ST is a ticket issued by CAS for users to access a service. When a user accesses the Service and the service finds that the user does not have an ST, the user is required to obtain the ST from CAS. The user sends an ST request to CAS. When CAS discovers that the user has a TGT, the CAS issues an ST and returns the ST to the user. The user uses the ST to access the Service, and the Service uses the ST to the CAS for authentication. After the authentication succeeds, the user is allowed to access resources.


The relationship between bills is shown below. Note that PGTIOU, PGT, PT are the contents of CAS 2.0, interested students can learn by themselves.

The detailed steps

Are you getting a little dizzy when you see this? That’s ok. Let’s use a simple scenario to walk through the detailed steps of implementing SSO with CAS and further understand the concepts presented earlier.

To start!

  1. The user accesses product A. The domain name is www.a.cn.
  2. As the user does not carry the COOKIE of A that is logged in to server A, server A returns an HTTP redirect. The redirect URL is the ADDRESS of the SSO server. In addition, the parameter in the QUERY of the URL indicates that after a successful login, the user will return to page A. The redirected URL is in the format of sso.dxy.cn/login?service=https%3A%2F%2Fwww.a.cn.
  3. Since the user does not carry the TGC that is logged in to the SSO server (see the ticket above), the SSO server determines that the user is not logged in and displays the unified login interface for the user. Users log in to the SSO page.
  4. After a successful login, the SSO server builds the TGT (another ticket) that the user logged in to at SSO and returns an HTTP redirect. Note here:
  • The redirect address is the page A previously written in query.
  • The query of the redirect address contains the ST sent by the SSO server.
  • The redirected HTTP response contains the header to write the cookie. This cookie represents the user’s login status in SSO and its value is TGC.
  • Browser redirects to product A. In this case, the REdirected URL carries the ST generated by the SSO server.
  • According to ST, server A sends a request to the SSO server, which verifies the ticket validity. After the authentication is successful, server A knows that the user has logged in in SSO. Therefore, server A establishes a user login session, which is denoted as A session. And writes the cookie to the browser. Note that the cookies and session here store the login status of the user on server A, and have nothing to do with CAS.
  • The user then visits product B, whose domain name is www.b.cn.
  • Since the user does not carry the COOKIE of B that is logged in to server B, server B returns an HTTP redirect with the URL of the SSO server to inquire about the user’s login status in SSO.
  • Browser redirects to SSO. Note that a cookie with a TGC has been written to the browser in step 4, so the SSO server can get it. If it finds a TGT, it will judge that the user has logged in to SSO.
  • The SSO server returns a redirect that carries ST. Notice that the ST here is not the same as the ST in step 4. In fact, the ST generated is different every time.
  • The browser redirects to server B with ST, as in step 5.
  • Server B sends a request to the SSO server based on the ticket. After the ticket verification is successful, server B knows that the user has logged in to SSO, so it generates SESSION B and writes cookie B to the browser.


    • As shown in the figure, at this point, the whole login process ends. After the user accesses A or B, a cookie/ B cookie is carried directly, and SSO confirmation is no longer required.

    In actual development, more judgment logic can be added according to CAS. For example, after receiving the ST issued by CAS Server, if THE HACKER steals the ST and the client does not have time to verify the ST, the hacker preempts the ST, how to solve the problem? At this point, you can add additional authentication factors (such as IP, sessionId, etc.) when applying for an ST.


    Reference reading:

    • CAS Official Documents