How CAS implements SSO single-point Logon

Security:

Users only need to enter the user name and password in CAS, and then bind the user through ticket. The CAS client verifies the user through ticket and does not transmit the password online, so security can be ensured, password is not stolen

Principle: 1 cookie + N sessions

CAS creates cookies when logging on to all applications. Each application creates its own session in IE to identify whether the application has logged on.

COOKIE: used when CAS is used to log on to various applications, so that only one user password is required.

Session: each application creates its own session to indicate whether to log on.

Login

1. Process CAS Logon:

Step 1: CAS add cookie (TGC) to the browser)

CAS sends a so-called "memory cookie" to the browser ". This cookie is not actually stored in the memory, but automatically expired as soon as the browser is closed. This cookie is called "Ticket-granting cookie", which indicates that the user has successfully logged on.

This cookie is an encrypted cookie that stores user login information. Used to log on to other application clients in the future.

Step 2: CAS simultaneously creates a ticket to redirect to the original CAS Client

After successful authentication, the CAS server creates a long, randomly generated String called "ticket ". CAS then associates the ticket with the successfully logged-on user and the service. This ticket is a one-time credential, which is used only once for successfully logged-on users and their services. Expired immediately after use.

2. CAS client applicationAProcessing

Step 1: Submit the verification ticket to CAS after receiving the ticket

CAS ClientAfter receiving the ticket, the application needs to verify the ticket. This is achieved by passing ticket to a validation URL. The verification URL is also provided by the CAS server. CAS obtains ticket through the verification path and determines it through the internal database. If it is determined to be valid, a netid is returned to the application. CAS then voided ticket and left a cookie on the client. (Who will create a cookie ?),

Step 2: Create a session after ticket Authentication

No ticket is available when you log on to this application later, but Ie can provide a session to obtain casreceept from the session, and verify that if the application has been authenticated, access to this application is allowed,

So far, CAS records that the user has logged on to application

3. log on to the applicationBHow to handle

When you enter application B, the user will first redirect to the CAS server. However, the CAS server does not require the user to enter the user name and password. Instead, it automatically searches for cookies and logs on based on the information saved in the cookies. CAS also redirects application B to CAS for verification (the process is the same as that of application a for verification). If the verification succeeds, application B creates the session record casreceipinformation to the session, log on to application B with this session later.

So far, CAS records that the user has logged on to application a and application B. However, when the user logs out of CAS on application B, application A should be notified to log out, how can I notify app?

Logout　　　

After CAS Server accepts the request, it detects the user's TCG cookie, clears the corresponding session, and finds all the application server URLs that are logged on through the tgc sso to submit the request, all callback requests contain the logoutrequest parameter in the following format:

<Samlp: logoutrequest id = "[random id]" version = "2.0" issueinstant = "[current date/time]">
<SAML: nameid> @ [email protected] </SAML: nameid>
<Samlp: sessionindex> [session identifier] </samlp: sessionindex>
</Samlp: logoutrequest>

All application servers that receive the request will parse this parameter and obtain the sessionid. After obtaining the session ID, the session will be deleted.
In this way, the single-point logout function is implemented.
 

Client implementation:

First, you must add the following configuration to implement Single Sign Out in Web. xml on the application side of the Application Server:

<Filter>
<Filter-Name> CAS Single Sign Out filter </filter-Name>
<Filter-class> org. JASIG. Cas. Client. session. singlesignoutfilter </filter-class>
</Filter>

<Filter-mapping>
<Filter-Name> CAS Single Sign Out filter </filter-Name>
<URL-pattern>/* </url-pattern>
</Filter-mapping>

<Listener>
<Listener-class> org. JASIG. Cas. Client. session. singlesignouthttpsessionlistener </listener-class>
</Listener>

NOTE: If CAS client filter is configured, the CAS Single Sign Out filter must be placed before the CAS client filter.

The configuration part aims to implement session clarity when CAS server calls back all applications for single-point logout.

 

 On the server side, applications that have been logged on will be saved on the server side. Therefore, the server separately clears sessions for each application by sending HTTP requests.

After reading the following browser cookie changes, we will have a deeper understanding of CAS.

Download httpwatch to monitor cookie changes

Client message process

1. First VisitHttp: // localhost: 8080/,

Client: no ticket and no message in the session.

CAS: users are required to log on if TGC is not available.

2. Jump back after successful authentication

CAS: generate the ST through TGT and send it to the client. The client saves the TGC and redirectsHttp: // localhost: 8080/

Client: Only CAS verification tickets are sent to the backend without a ticket (this process cannot be seen in the browser)

3. First VisitHttp: // localhost: 8080/B

Client: no ticket and no message in the session.

CAS: extracts the TGC from the client. If the TGC is valid, it is sent to the user st and verified in the background for SSO. [How can I notify other systems to update the session information when a logon or logout fails ?? This. Services. Put (ID, Service) in the ticketgrantingticketimpl grantserviceticket method; it can be seen that the CAS side has recorded the current login subsystem]

4. Access againHttp: // localhost: 8080/

Client: No ticket, but there is a message in the session, so no jump or CAS authentication ticket is required, allowing users to access