Implement SSO using Yale CAS +. Net client (3)

• Part 1: install and configure Tomcat
• Part 2: install and configure cas

Part 3: Implement ASP. NET webform Client

1. Download. Net CAS client.

. Net CAS client: https://wiki.jasig.org/display/CASC/.Net+Cas+Client

Download and decompress unzip dotnet-client-1.0-src.zip.

 

2. Configure CAS dotnetclient

Start Visual Studio as an administrator (to publish the website directly to IIS) and open the "dotnetcasclient. vs2010.sln" solution.

(1) The project "dotnetcasproxydemoapp" is temporarily unavailable and will be removed from the solution.

(2) Delete "assemblyinfo. cs" in the "properties" folder of the "dotnetcasclient" project and rename "assemblyinfo. cs. tmpl" to "assemblyinfo. cs ".

(3) Open the "assemblyinfo" under the "properties" folder in the "dotnetcasclient" project. CS, replace all "$ wcrev $" with "0" (or other numbers that represent the version ).

(4) set the "examplewebsite" project as a startup Item.

(5) Rename "Web. config. sample" in the root folder of the "examplewebsite" project to "Web. config"

(6) Open the "Web. config" file, find the "casclientconfig" node, and set"Casserverloginurl"Property is set to"Https: // 192.168.0.123: 8443/CAS/login",Casserverurlprefix"Property is set to"Https: // 192.168.0.123: 8443/CAS/",Servername"Property is set to"Http: // localhost: 3273/examplewebsite".

Note: 192.168.0.123 is the configured CAS Server IP address. In the "servername" attribute, 3273 is the port number automatically allocated by iisexpress when the project is running. If the project is published to the client IIS, we recommend that you change the "servername" attribute to "http: // 192.168.0.153/examplewebsite", where 192.168.0.153 is the Client IP address. Note: Do not add "/" at the end of the network address in the "servername" attribute.

(7) Find the "authentication" node from the "Web. config" file andLoginurl"Property is set to"Https: // 192.168.0.123: 8443/CAS/login",Path"Property is set to"/Examplewebsite/".

(8) save all the modifications and recompile the solution.

 

3. debug CAS dotnetclient

(1) Right-click "default. aspx" in the root directory of the "dotnetcasclient" project and select "view..." in the browser ..."

(2) Click "Authenticated Users Only" to connect to the CAS logon page. (If IE has certificate warning information, click "continue to browse this Website "), at this time, ie will report a webpage error.

This is caused by a script in CAS ., The debugging information indicates that there is a problem with the "CAs/JS/CAS. js" script.

(3) Go Back To The server whose IP address is "192.168.0.123", edit "% atat_home % \ webapps \ CAS \ JS \ cas. js" as an administrator, and scroll to the bottom of the file to add two linesCodeAnd save. :

(4) Return to the client machine and repeat step (1). This time, ie no longer reports any webpage error.

Note: we strongly recommend that you clear ie cache and cookies each time you run the project to prevent unnecessary mistakes caused by IE cache.

(5) enter the username and password in the CAS logon form, both of which are "admin". In this case, a logon exception occurs, or IE prompts you to log on again and again, or ie may be suspended. If you use the chorme browser, you will find a "redirection loop" problem.

 

4. Solve the Problem of CAS dotnetclient redirection Loop

CAS dotnetclient redirection loops have long been detected and various solutions have been proposed. After searching, we will find that the most helpful thing is the analysis of "circular redirection" integrated by CAS and. net in the blog Park "shao. In this blog, we recommend that you add the following configurations:

<Sessionstate mode = "StateServer" cookieless = "usecookies" timeout = "36000"> </sessionstate>

The objective is to: 1. Enable session status; 2. Start Asp.net Status Service (ensure session persistence, not inexplicable failure. 〕.

However, through tracking and analysis of the project "dotnetcasclient" code, it is found that the status information is stored through cache, and the relationship with sessionstate should be small. I think this method cannot solve the problem.

Set a breakpoint in "dotnetcasclient \ validation \ ticketvalidator \ abstracturlticketvalidator. cs" and run it step by step through F11ProgramThe problem was found: "The basic connection has been closed: failed to establish a trust relationship for the SSL/TLS security channel ."

 

Therefore, the following solutions are provided:

(1) Open the "\ utils \ httputil. cs" file in the "casdotnetclient" project in Visual Studio and add the following namespace:

 
UsingSystem. net. Security;UsingSystem. Security. authentication;UsingSystem. Security. cryptography. x509certificates;
 

(2) Add the following method to the httputil class:

 
Internal Static BoolCheckvalidationresult (ObjectSender, x509certificate certificate, x509chain chain, sslpolicyerrors errors ){Return True;}
 

(3) Add the automatic verification code for the verification server certificate callback in the verimhttpget method. After the code is added, the verimhttpget method is as follows:

 Internal   Static   String Performhttpget ( String URL, Bool  Requirehttp200 ){  String Responsebody = Null  ;  //  -- The following newly added code: Verify the automatic verification of server certificate callback Servicepointmanager. servercertificatevalidationcallback = New System. net. Security. remotecertificatevalidationcallback (checkvalidationresult );  //  -- The code above is newly added  Httpwebrequest request = (Httpwebrequest) webrequest. Create (URL );  Using (Httpwebresponse response = (Httpwebresponse) request. getresponse ()){  If (! Requirehttp200 | response. statuscode = Httpstatuscode. OK ){  Using (Stream responsestream =Response. getresponsestream ()){  If (Responsestream! = Null  ){  Using (Streamreader responsereader = New  Streamreader (responsestream) {responsebody = Responsereader. readtoend ();}}}}}  Return  Responsebody ;} 

(4) Save the changes and regenerate the solution.

 

5. Test CAS dotnetclient

(1) Right-click "default. aspx" in the root directory of the "dotnetcasclient" project and select "view..." in the browser ..."

(2) Click authenticated users only. The system automatically redirects to the CAS logon page. (If IE has certificate warning information, click Continue to browse this website ").

(3) enter the user name and password (both "admin" and "Bob"). CAS automatically logs on and redirects back to the original website.

So far, the CAS client Based on ASP. NET webform has been fully debugged. Next we will further discuss the "redirection loop ".

 

6. Discuss dotnetclient redirection loop in Depth

Here are two solutions I found online, and I will discuss the existing problems.

(1) howto casifying ASP. NET webapp-examplewebsite

This article should be a solution released on the official website and should be authoritative. The main solution provided by the CA is to allow CAS server and CAS client to trust the certificate of the other party, so as to avoid the redirection loop caused by the untrusted Certificate of SSL. However, the actual situation is that IE does not trust the certificate generated by the user, even if it is added to the trusted Certificate root list, resulting in a "redirection loop" still exists.

In addition, this articleArticleIt is not necessary to configure IIS to support SSL. IIS can run normally without configuring SSL. Of course, for the sake of security, configuring SSL does not have any harm.

(2) analysis on the issue of "circular redirection" integrated by CAS and. net in the "Shao shao" blog

This article attempts to solve the problem from the sessionstate configuration, but in my practice, the "Redirect loop" is not solved, and the essence of the "Redirect loop" problem is the SSL Certificate Trust problem.

 

7. dotnetclient logout

There are many materials to introduce about DOTNET deregistration. I will not talk more here. Leave a link for your reference. Explanation of CAS logout Problems

For ease of viewing, the main content of "Explanation of CAS logout problems" is as follows:

CAS logout is a very confusing problem. Here I will explain it briefly:

Assume that webapp1, webapp2, CAS server, webapp1, and webapp2 are all protected by CAS server.

 

1st cases of logout failure:

1) log on to webapp1, redirect to caserver, and redirect to webapp1 after casserver authentication. OK!

2) When the HTTP method is lougout casserver1, that is, http: // yale_casserver: 8080/CAS/lougout, the logout is successful.

3) Access webapp2 and access! This is a very normal situation, because you do not use HTTPS to log out, how does casserver "kill" The TGC cookie sent to you through HTTPS?

 

2nd cases of logout failure:

1) log on to webapp1, redirect to caserver, and redirect to webapp1 after casserver authentication. OK!

2) the result of a successful logout is displayed in the format of lougout casserver1 in https mode, that is, https: // yale_casserver: 8443/CAS/lougout.

3) Access webapp1 and access! Access webapp2, no access, redirection to casserver requires login! This is also a very normal situation, because you have been able to access, you can continue to access, caslogout cannot prevent you from accessing webapp1, it can only prevent you from accessing webapp2, because you are already allowed to access webapp1, but webapp2 is not. If you also access webapp2 at (1), your logout will be useless, CAS cannot prevent you from accessing these two webapps because you have service ticket.

If you are confused about this, it is because you have logged out of the system because CAS logout does not work like this, the function of TGC is to prevent you from getting the ST through TGC (it simply understands the TGC cookie of IE), and prevent you from getting the ticket to other web applications.

Therefore, when webapp1 is used up, log out, and then close IE to complete logout.

 

To be continued...