CAS (4)--cas browser SSO access sequence diagram detailed (CAS Web Flow Diagram by Example)

CAS (4)--cas browser SSO access sequence diagram detailed (CAS Web Flow Diagram by Example)

Tomcat version: tomcat-8.0.29

JDK version: jdk1.8.0_65

Nginx Version: nginx-1.9.8

CAS version: cas4.1.2
cas-client-3.4.1

Reference Source:

Jasig.github.io:CAS protocol

CAS (1)--mac configure CAs to Tomcat (server side)

CAS (2)--mac configuring CAs to tomcat (client)

Cas (01)--Introduction

CAS (09)--access other CAS applications via proxy

Sequence diagram: (from http://jasig.github.io/cas/4.0.x/protocol/CAS-Protocol.html)

(1) First time user access (GET:HTTPS://APP1.HOAU.COM:8413/CAS1)

Because SSL is local configuration, the browser does not trust the current certificate, so it will prompt "Net::err_cert_authority_invalid"
Detailed information is as follows:

Click "Advanced" and select "Continue to app1.hoau.com (unsafe)"

(2) Access is not authenticated at this time (unauthenticated)

So the server goes to the CAS, plus the query parameter "service".

How is it implemented?

We can see that the status code returned in the header of the HTTP GET request is "302 Found"

URL: https://app1.hoau.com:8413/cas1Status Code: 302 Found

In the Response header,

Location:https://sso.hoau.com:8433/cas/login?service=https%3A%2F%2Fapp1.hoau.com%3A8413%2Fcas1

The APP1 service will request redirection (redirect) to the CAS service.

(3) The browser initiates a request with parameters to the CAS server

Location:https://sso.hoau.com:8433/cas/login?service=https%3A%2F%2Fapp1.hoau.com%3A8413%2Fcas1

* Note: There may still be cookie information TGC and casprivacy in the client browser, but it is found in the response header that the server will empty the two cookies and return a Jsessionid

JSESSIONID=8534DCE475C44FF446D1DE2250426B1F

At this point, the CAS server discovers that the user does not have SSO session.

(4) So return to the login page

(5) Login SSO (user name/password: test01/psw01)

You can notice that the Post method is used to send the username and password, including the logged-in ticket, to the CAS server

Form:

Tgc:

The CAS server then validates the submitted user name password if the validation passes.

(6) CAS server will do a few things

• Create SSO Session
• Create a CASTGC Cookie (TGC in the figure here)

* Note: This session-level cookie contains information about the Ticket granting Ticket (TGT).

set-Cookies: Tgc=eyjhbgcioijiuzuxmij9.zxlkagjhy2lpaupryvhjauxdsmxibu1pt2lkqk1ustrrmepetfvove1qvtjjbjaulmnfck5eb2fkwgzkqndvmdbcn2gwnmcuu0nlvjvasllvtjjzbmnururmqjdur2tpngz4ny14rxatznctywrhqlbuou4wys1zu0d  PAE12MXNUUKXMRG1SYVV0U1NQM0PRQZBRNERUOFZVD2DJU0VMYVBMDZFGDFNTDGHP  ZDN3CE1IVHZZBULMOXFQYKZ3Q0F3EW9PD3PJRMJHN1HZSHI2MHBHYJH5BFZZBHHPA  W12wlprqnjvefpvr3hrqtj1zvzhbknnq09vykxsy0rfq0noqnj4mm5an19ocfjoyk  Z1lvzrdtv3c2fxumxkts05lwfgc1otqxbpwenxoehjqlreuhbvouvqwfhdz204t00xmxutsldkddbcry1bvkl0zulkt0fgy3vomxd4rwdyx0euzuqzyjrgukh Kby1iamlcbmnnmdlpzw. wwel14ipwvub5c2poe-xq38i1ssn1glpclnxa7rkt7av0bowaur9waut8lpdmel3ycjev0whyanaetv_hid08 A; path=/cas/; Secure; httponly            

The last response of this request will also be passed "302 Found", which will

(7) Browser redirection to protected App

Location:https://app1.hoau.com:8413/cas1?ticket=ST-1-RNCht4LbpbALUYWPnR7K-cas01.sso.hoau.com

At this point, the browser will bring the obtained ticket to the app to re-request login,

(8) After the Protected app receives the request

Sends a request to the CAS server to verify the legality of the ticket

(9) The CAS server then returns an XML content

(including success information, authentication object and some other optional parameters)

* HERE (8), (9) Two steps to use Tcpmon Receive Message view (10) If successful, the Protected app will be the corresponding (7) request

redirect the browser to the target page of the protected app with "302 Found" and set the Jsessionid of the cookie

content-Length:0Date: Tue,15Dec201501:56: 41 gmtLocation:https://app1.hoau. Com:8413/cas1;jsessionid= 3d16483c31f8358a561e8edccc1c196d.tomcat1server: Apache-coyote/1.1set-Cookie< Span class= "Hljs-symbol" >:jsessionid=3D16483C31F8358A561E8EDCCC1C196D.TOMCAT1; path=/cas1/; secure; httponly             

(11) Browser with Cookie:jsessionid access to the target app's page

(12) Login success, Protected app return status Code 200 and page content

Access the same app again

Sequence diagram: (from http://jasig.github.io/cas/4.0.x/protocol/CAS-Protocol.html)

(1) The browser with the first authentication after the Cookie:jsessionid Access Protected app (2) Protected app check session Cookie

If successful, return to the back page.

But I'm having a problem with the test.

When there is a second visit, there are actually 4 requests, and the only difference from the first visit is that the user name and password are missing the input process, but the checksum of the session cookie on the protected app does not pass.

You can see that the protected app redirects the browser to the CAS server (1) and generates a new ticket for the client.

“ticket=ST-4-s2ffmz3oJZTax5XMV4x7-cas01.sso.hoau.com”

* Suspect that the protected app does not maintain session status

To verify this idea, we re-visited

https://app1.hoau.com:8413/cas1

It is found that after the above 4 request verification, the browser URL will be brought on the Jsessionid, if the request parameter is deleted, then the 4-segment request will be re-passed.

If you do not delete and refresh the page directly, the behavior of the system interaction is consistent with the behavior described in the official online sequence diagram.

Try to modify the settings of the Protected app Web. xml

Increase Singlesignoutfilter

<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>             

Knot

The result is still invalid, or 4-paragraph request.

Try changing the browser to test

found that the IE kernel browser behavior, and our previous test with the chrome consistent, if the URL after the deletion of Jsessionid, then the same will go through 4 requests.

Firefox browser will be a little different, after removing the URL after the Jsessionid, Firefox's next request still with a cookie

* Suspicious of Browser cookie Write permission settings

In Chrome, manage exceptions in "settings---Advanced, privacy settings,->cookie", and add app1.hoau.com and sso.hoau.com to the exception settings.

Then try to remove the URL after the Jsessionid parameter, again access

https://app1.hoau.com:8413/cas1

Finally got the results we wanted.

Access another app in the same domain

Sequence diagram: (from http://jasig.github.io/cas/4.0.x/protocol/CAS-Protocol.html)

(0) After accessing the protected app

https://app1.hoau.com:8413/cas1

, we can see that the CAS server has generated CASTGC, and this value will be used when accessing another application.

eyJhbGciOiJIUzUxMiJ9.ZXlKaGJHY2lPaUprYVhJaUxDSmxibU1pT2lKQk1USTRRMEpETFVoVE1qVTJJbjAuLndBeWRVeGpIODE4Z0I4X29DSFBXYXcuVHVaOE5BN0tQZGJlSU5NSUZjNGZSQUVacDdUeGFFQkNJU2FONVFEYVRrVUpYR3VyUlpDeEloTktxTFljci1jNGJVdjdQLWc5MW9uaEUtU0VNSHV4RUU4dGpMeDRtMkg0RGNWbFJyTkJiR0NEOUljSzNNZFZjV1BCRDduSFpwZ3E5VmI1emJMRV9GSmJjY1ZwZU5QdXRhOEp0M1g4b0NLVjQzanozeHA1WlRfR0xkdjdmdjZlMmtEMnBTRXRIOG5UcS04NFpmNFlEcGZ4c1Z2WDhlMVZLb0ZRcndyWUJpdGpnU0c4TkxPVHB5dy5TQURjZmN2cGhnbkJJT0NKNlRLd1pB.hsIsZNJHWfrqQJ3kj4z18WctFpxeVPDQv9ONeK4yRVRSNBNprlfYJ_toa9hbNozf_rGYOYySEdMJbSvR5IMa-A

(1) Access to another application

https://app2.hoau.com:8423/cas2

Then

(2) Protected App #2无法对用户进行认证

The server returns the redirect status code "302 Found" to redirect the browser to the CAS server

Location:"https://sso.hoau.com:8433/cas/login?service=https%3A%2F%2Fapp2.hoau.com%3A8423%2Fcas2" 

(3) The browser tries to access the CAS server

and carry the current session and scene one through the app #1认证时获取的Cookie CASTGC

https://sso.hoau.com:8433/cas/login?service=https://app2.hoau.com:8423/cas2    

(4) CAS server Authentication ticket redirect

Since the CAS server still has the state of the previous CASTGC, redirect the browser again to App # #

Location:"https://app2.hoau.com:8423/cas2?ticket=ST-58-TilmxEy20VOmDQuSdIx1-cas01.sso.hoau.com"

(5) The browser accesses the address of app # via redirection

https://app2.hoau.com:8423/cas2

And then

(6) Protected App #2会向CAS服务器再次发起请求

This will bring the protected App #2生成的ticket

ticket=ST-58-TilmxEy20VOmDQuSdIx1-cas01.sso.hoau.com

(7) If the validation succeeds, the CAS server returns the XML content that contains the success information accordingly

and redirect the browser to the protected App #2的登陆后页面

* HERE (6), (7) Two steps to use Tcpmon received message view, because the test forgot to match Tcpmon, may be some parameter value is not on, in this apology (8) Protected App #2的验证通过后, try to redirect to landing a successful page

(9) The browser carries the CAS cookie request app #2的登陆成功页

Protected App #2再次校验Session Cookies

(10) If the verification is successful, the content of the landing Success page is returned.

End

(EXT) CAs (4)--cas browser SSO access sequence diagram in detail (CAS Web Flow Diagram by Example)