Cookie single sign-on implementation is very simple, but also a lot of problems. For example, the user name and password are constantly transmitted, increasing the possibility of stolen numbers. In addition, cannot cross domain!
1. Review of cookie-based single sign-on
The user name and password will be encrypted and stored in the Cookie, and then the user’s permission will be verified in the filter when visiting the website. If there is no permission, the user name and password will be taken out from the Cookie for login, so that the user can feel that he has logged in only once in a sense.
The disadvantages of this method are that the user name and password are transmitted multiple times, which increases the risk of theft and cannot cross domains. Click here to learn how Java can cross domains. At the same time, www.qiandu.com and mail.qiandu.com have the code of login logic at the same time. If modification operation is involved, two need to be modified.
2, unified certification center scheme principle
In life, we also have similar related life experience, for example, you go to the canteen to eat, the canteen canteen rice aunt (www.qiandu.com) told you, do not accept cash. And tell you, you go to the ticket changer at the door (passport.com) to change the receipt. So after you change the ticket, and then go to the canteen aunt, the canteen aunt took your ticket, ask the door change ticket, is this ticket real? The guy who changed the ticket said, “It’s true.” So HE gave you a meal.
Based on the above life scenarios, we improved the cookie-based single sign-on scheme as follows:
Step 1: Users go to www.qiandu.com. The filter determines whether the user is logged in. If not, the user is redirected (302) to the website http://passport.com.
Step 2: Redirect to Passport.com and enter your username and password. Passport.com logs user login information into the server’s session.
Step 3: Passport.com sends a special certificate to the browser. The browser gives the certificate to www.qiandu.com. www.qiandu.com takes the certificate to Passport.com to verify that the certificate is valid and determine whether the user has logged in successfully
Step 4: The login is successful, and the browser and website can be accessed normally.
3. Central Authentication Server (CAS) developed by Yelu University
Here’s how it works, based on the CAS developed by Yale University. Take a look at the top level project deployment diagram first:
Deploying a project requires the deployment of an independent authentication authority (cas.qiandu.com) and N other users’ own Web services.
Authentication center: namely cas.qiandu.com, namely CAS-server. The CAS framework provides authentication services. Users only need to implement authentication based on the logic of services.
User Web projects: You only need to configure several filters in web. XML to protect resources. The filters are also provided by the CAS framework, namely cas-client.
4. Detailed CAS login process
The figure above shows three login scenarios: first access to www.qiandu.com, second access, and first access to mail.qiandu.com in the login state.
Below is a detailed description of what each number in the figure does, along with the associated request and response content.
4.1. First visit to www.qiandu.com
Label 1: The user visits http://www.qiandu.com through his first filter (provided by CAS and configured in web.xml) AuthenticationFilter.
Filter full name: org. Jasig. Cas. Client. Authentication. AuthenticationFilter
Main function: Checks whether you have logged in. If you have not logged in, you are redirected to the authentication center.
Label 2: www.qiandu.com If the user is not logged in, the browser redirection address is returned.
You can first see that we requested www.qiandu.com, and the browser returned a status code of 302, then redirected the browser to cas.qiandu.com and added the parameter service via get. The purpose of this parameter is to be redirected back after a successful login, so this parameter is needed. And you’ll notice that the server value is actually the encoded address we requested www.qiandu.com.
Label 3: The browser receives the redirect and redirects it, requesting cas.qiandu.com.
Label 4: Cas.qiandu.com has received the login request and returns to the login page.
The picture above shows the request number 3 and the response number 4. The requested URL is the URL returned by label 2. The authentication center then displays the login page and waits for the user to enter the user name and password.
Label 5: The user enters the username and password on the login page of cas.qiandu.com and submits.
Label 6: the authentication is valid if the server receives the username and password. The authentication logic can be provided by the CAS-server or implemented by itself.
The picture above shows the request number 5 and the response number 6. When cas.qiandu.com, or CSA-server, is authenticated, it is returned to the browser 302, and the redirected address is the value of the service parameter in the Referer. The ticket is ST (digit 3). A CASTGC is also set in the Cookie, which is a Cookie from the site cas.qiandu.com, and is carried only when you visit the site.
CASTGC in Cookie: The purpose of adding this value to the Cookie is that the next time you visit cas.qiandu.com, the browser carries the TGC in the Cookie to the server, which looks up the corresponding TGT based on this TGC. To determine whether the user has logged in and whether the login page needs to be displayed. A TGT is to a TGC what a SESSION is to a SESSIONID in a Cookie. Click here to learn how Java works with cookies.
Ticket Granted Ticket TGT: Ticket Granted Ticket
TGC: Ticket Granted Cookie (value in Cookie), stored in Cookie, based on which the TGT can be found.
ST: Service Ticket (small token), which is generated by the TGT and takes effect after being used once by default. So that’s the ticket value at number 3.
No. 7: After the browser picks up a ticket from cas.qiandu.com, it is instructed to redirect to www.qiandu.com. The requested URL is the one returned above.
8: www.qiandu.com The value of ticket is obtained in the filter, and cas.qiandu.com is invoked through HTTP to verify whether the ticket is valid.
9 cas.qiandu.com Verifies that a ticket is received. The authentication result is returned to tell www.qiandu.com that the ticket is valid.
No. 10: www.qiandu.com Receives the response from the CAS-server. After knowing that the user is valid, display related resources to the user’s browser.
At this point, the whole process of the first access is over. The links labeled 8 and 9 are called through the code, not initiated by the browser, so the message is not intercepted.
4.2. Second visit www.qiandu.com
I visited it once. What happens when I visit it a second time?
Label 11: User initiates a request to visit www.qiandu.com. After the first successful access, the user information will be recorded in www.qiandu.com session. Therefore, it will pass directly without authentication.
Label 12: The browser returns normal resources after the user passes the permission authentication.
4.3. Visit mail.qiandu.com
Number 13: A user who is normally on the Internet at www.qiandu.com suddenly wants to access mail.qiandu.com and initiates a request to access mail.qiandu.com.
The 14:mail.qiandu.com received the request and found the first access, so he was given a redirected address and told to find the authentication authority to log in.
As you can see above, the user requests mail.qiandu.com and is returned with a url, status 302 redirect, and the service parameter is the address that comes back.
Label 15: the browser will initiate a redirection based on the address returned by 14. Since it has been visited once before, this time it will carry the Cookie: TGC returned last time to the authentication center.
Label 16: The certification authority receives the request, finds that a TGC corresponds to a TGT, issues an ST with the TGT, and returns it to the browser to redirect to mail.qiandu.com
You can see that the request carries a Cookie: CASTGC, and the response is an address plus a TGT issued ST, or ticket.
Label 17: The browser initiates a redirect based on the url returned by 16.
18:mail.qiandu.com Obtains ticket and goes to the authentication center to verify whether the ticket is valid.
Label 19: Successful authentication, return to mail.qiandu.com session to set login status, next time login directly.
Label 20: After successful authentication, you can use the resource you want to access anyway.
5, summary
At this point, the whole process of CAS login is completed. Later, there is time to summarize how to use CAS and apply it to the project.
More exciting articles, pay attention to the public number [ToBeTopJavaer], but also the following tens of thousands of yuan boutique VIP resources for free waiting for you to take!!Copy the code
