OK ... so we've resurrected (rebuilt) our dev. server and I'm back to working on this ...
As I understand it, turning the poxy support off is a matter of removing the proxyTicketManager in the web.config (which I did ... commented it out). Same result. I think I came across (previously) the the hack which you mention, and I'm not that desperate yet (and probably won't ever be ... kind of self-defeating). Again ... CAS server is validating (see log snippet below) and issuing tickets. Local .net app (using example web site as test case before I try to implement on my own app) is just not accepting and issuing the cookie. Back to tracing through it, but if there are any other insights, they would be greatly appreciated. 2010-09-14 14:24:37,539 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service ticket [ST-72-9MCSH7koVWZUp1O3UAcc-cas] for service [https://cas-eg.server:8443/Restricted/UsersRoleOnly/default.aspx] for user [jwhite]> 2010-09-14 14:24:37,676 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service ticket [ST-73-yCMVlH7jkoZR6cFxmmfn-cas] for service [https://cas-eg.server:8443/Restricted/UsersRoleOnly/default.aspx] for user [jwhite]> 2010-09-14 14:24:37,729 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service ticket [ST-74-MkkiXoJF70eh7ZUIugko-cas] for service [https://cas-eg.server:8443/Restricted/UsersRoleOnly/default.aspx] for user [jwhite]> 2010-09-14 14:24:37,784 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service ticket [ST-75-BHA59n22lFSoscu4eoK7-cas] for service [https://cas-eg.server:8443/Restricted/UsersRoleOnly/default.aspx] for user [jwhite]> 2010-09-14 14:24:37,842 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service ticket [ST-76-wNzhLgacTifduzQqXAey-cas] for service [https://cas-eg.server:8443/Restricted/UsersRoleOnly/default.aspx] for user [jwhite]> 2010-09-14 14:24:37,949 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service ticket [ST-77-cF3JTAmouVeKNtxwismv-cas] for service [https://cas-eg.server:8443/Restricted/UsersRoleOnly/default.aspx] for user [jwhite]> 2010-09-14 14:24:38,010 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service ticket [ST-78-QUCx5Fi7bIfGjOxMUSrb-cas] for service [https://cas-eg.server:8443/Restricted/UsersRoleOnly/default.aspx] for user [jwhite]> TIA, Jason ________________________________________ From: Scott M. Holodak [[email protected]] Sent: Wednesday, September 01, 2010 5:02 PM To: [email protected] Subject: RE: [cas-dev] .Net CAS Client (w/MVC 2) Hi, Your app server needs to trust the certificate chain of your CAS server. Google ServicePointManager.ServerCertificateValidationCallback for a potentially dangerous hack to get around this. Also if you have proxy support turned on, your CAS server needs to trust the development certificate that you created for you web app. To get around this, try turning the proxy feature off in the client. You won't be able to generate (and validate? Not sure) proxy tickets. Then it will use serviceValidate instead of proxyValidate and it should bypass SSL problems between from the CAS server to your app server. -ScottH > -----Original Message----- > From: Jason Edward White [mailto:[email protected]] > Sent: Wednesday, September 01, 2010 4:18 PM > To: [email protected] > Subject: RE:[cas-dev] .Net CAS Client (w/MVC 2) > > Scott Holodak and I have been back and forth a little on this > privately. decided to join and bring this to the list. > > I'm having an issue with CAS authentication with the .net cas client > when deployed on the server. It seems to run fine from Visual Studio, > but not from the server. I'm using the example site as my baseline to > get comfortable with the .Net CAS Client for MVC, then I plan to port > it to our app. > > In the try/catch for CasAuthentication.cs >> ProcessTicketValidation I > added > > Log.DebugFormat("******** ProcessTicketValiation - > TicketValidationException {0}; {1}; {2} ************", t.Message, > t.InnerException, t.Source); > ... to the catch block. > > This is the result: > 2010-08-27 16:39:22,140 [7] DEBUG CasAuthentication - ******** > ProcessTicketValiation - TicketValidationException CAS server ticket > validation threw an Exception; System.Net.WebException: The underlying > connection was closed: Could not establish trust relationship for the > SSL/TLS secure channel. ---> > System.Security.Authentication.AuthenticationException: The remote > certificate is invalid according to the validation procedure. > > Since the difference is my local box to the server, I imagined it was a > cert issue. > > Important to note ... I have created a CA in the development > environment and have imported the root signing cert on my desktop and > on the servers (using keytool on the linux/CAS box and with the cert. > install utility on windows). So, it should not be an issue of the > trust/chain as far as I can see. We rebooted it for good measure, but > it's taking FOREVER to reboot. While I wait to see what's up with that > (and potentially rebuild my development server) ... Any insights/ideas? > > TIA! > > Jason > > ________________________________________ > From: Jason Edward White > Sent: Friday, August 27, 2010 4:02 PM > To: Scott M. Holodak > Subject: RE: .Net CAS Client (w/MVC 2) > > Sorry on one count ... the app server should have been: > https://cas-eg.foo.umd.edu > ... and the cas server: > https://sso-dev.foo.umd.edu > > Sorry ... habit of obfuscating log posts in email, lists, forums etc. I > mangled that one. Am working the SSL/Trust angle now. that is what the > innerException is telling me it is. > > Thanks, > Jason > ________________________________________ > From: Scott M. Holodak [[email protected]] > Sent: Friday, August 27, 2010 3:05 PM > To: Jason Edward White > Subject: RE: .Net CAS Client (w/MVC 2) > > Hi, > > A redirect loop (browser detects infinite/broken redirection on the > page) is generally cookie related. I haven't tested an app at the root > of the server... I always did development in an application off of the > root. It's possible you've found a bug in the client. > > A re-login loop (you are prompted for CAS credentials over and over > again or you get stuck at the 'you are already logged in' CAS page) > could be ticket validation related, which are often SSL related. The > log from the CAS server looks good as far as the CAS server assigning a > ticket. You'll want to look at the logs on the proxyValidate step a > few > lines down from there. proxyValidate requires that the CAS server > trusts the entire SSL certificate chain of the app server. The CAS > server makes a connection back to the app server over SSL as part of > the > CAS 2.0 protocol surrounding Proxy Granting Tickets. I noticed your > CAS > server and your app server are both at sso-dev.foo.umd.edu. I'm > assuming that your /cas/login is the IIS-Tomcat bridge or something > like > that. You might want to look out for SSL related errors in the CAS > server logs. It could be an issue that both the CAS server and the app > server both have the same host name. You might also try turning off > proxy support by removing the ProxyTicketManager or setting the proxy > option to false in the CAS configuration in web.config. This would > cause the client to use serviceValidate instead, skipping the PGT > handshake. It will at least let you rule out SSL. > > Another possible, though highly unlikely cause is that somehow the > FormsAuthenticationCookie > 4096 bytes which might cause your browser > to > ignore it. Also, some browsers assign limits on the number of or size > of outstanding cookies to a particular domain. If you're not already, > try using the CacheTicketManager. It reduces the footprint of the > cookie and stores more of the data on the server and less on the > client. > If you have other applications on that server that generate a large > number of cookies, you might try deleting your cookies for that entire > domain (sso-dev.foo.umd.edu). > > Keep me in the loop, especially if you think it looks like a bug in the > client. I'm trying to lock down a v1.0 release of the client shortly > and would definitely want to address an issue of this severity before > the release. > > -Scott > > > -----Original Message----- > > From: Jason Edward White [mailto:[email protected]] > > Sent: Friday, August 27, 2010 2:46 PM > > To: Scott M. Holodak > > Subject: RE: .Net CAS Client (w/MVC 2) > > > > Tried that ... it has to be at least one char. Also tried "/" ... > same > > redirect endless loop. Have traced it down to a > > TicketValidationException (but no more detail than that yet) in > > CasAuthentication.cs >> ProcessTicketValidation. the ... > > > > try > > { > > // Attempt to authenticate the ticket and resolve to > an > > ICasPrincipal > > string serviceUrl = > > > UrlUtil.ConstructServiceUrl(RequestEvaluator.GetRequestHasGatewayParame > > ter()); > > principal = TicketValidator.Validate(ticket, > > serviceUrl); > > ... > > } > > catch (TicketValidationException t) > > { > > Log.DebugFormat("******** ProcessTicketValiation - > > TicketValidationException ({0}) ************", t.Message); > > // Leave principal null. This might not have been a > > CAS service ticket. > > } > > > > The message sequence goes like this (mine has the *'s in it): > > > > 2010-08-27 14:38:20,437 [5] DEBUG CasAuthenticationModule - Starting > > BeginRequest for /Restricted/UsersRoleOnly/default.aspx > > 2010-08-27 14:38:20,452 [5] DEBUG CasAuthenticationModule - Ending > > BeginRequest for /Restricted/UsersRoleOnly/default.aspx > > 2010-08-27 14:38:20,452 [5] DEBUG CasAuthenticationModule - Starting > > AuthenticateRequest for /Restricted/UsersRoleOnly/default.aspx > > 2010-08-27 14:38:20,452 [5] DEBUG CasAuthenticationModule - Ending > > AuthenticateRequest for /Restricted/UsersRoleOnly/default.aspx > > 2010-08-27 14:38:20,452 [5] DEBUG CasAuthenticationModule - Starting > > EndRequest for /Restricted/UsersRoleOnly/default.aspx > > 2010-08-27 14:38:20,452 [5] DEBUG CasAuthenticationModule - > > Redirecting to CAS Login Page > > 2010-08-27 14:38:20,452 [5] DEBUG UrlUtil - > ConstructServiceUrl:return > > generated serviceUri: https://sso- > > dev.foo.umd.edu/Restricted/UsersRoleOnly/default.aspx > > 2010-08-27 14:38:20,452 [5] DEBUG UrlUtil - > ConstructLoginRedirectUrl: > > redirectToUrl=>https://sso- > > dev.foo.umd.edu/cas/login?service=https%3a%2f%2fsso- > > dev.foo.umd.edu%2fRestricted%2fUsersRoleOnly%2fdefault.aspx< > > 2010-08-27 14:38:20,452 [5] DEBUG CasAuthenticationModule - Ending > > EndRequest for /Restricted/UsersRoleOnly/default.aspx > > 2010-08-27 14:38:20,515 [5] DEBUG CasAuthenticationModule - Starting > > BeginRequest for /Restricted/UsersRoleOnly/default.aspx?ticket=ST- > 962- > > dyFiQ7ahWVR4SyjyfOzE-cas > > 2010-08-27 14:38:20,515 [5] DEBUG CasAuthenticationModule - Ending > > BeginRequest for /Restricted/UsersRoleOnly/default.aspx?ticket=ST- > 962- > > dyFiQ7ahWVR4SyjyfOzE-cas > > 2010-08-27 14:38:20,515 [5] DEBUG CasAuthenticationModule - > Processing > > Proxy Callback request > > 2010-08-27 14:38:20,515 [5] DEBUG UrlUtil - > ConstructServiceUrl:return > > generated serviceUri: https://sso- > > dev.foo.umd.edu/Restricted/UsersRoleOnly/default.aspx > > 2010-08-27 14:38:20,515 [5] DEBUG AbstractUrlTicketValidator - > > Validate:Constructed validation url:https://sso- > > dev.foo.umd.edu/cas/proxyValidate?ticket=ST-962-dyFiQ7ahWVR4SyjyfOzE- > > cas&service=https%3a%2f%2fsso- > > > dev.foo.umd.edu%2fRestricted%2fUsersRoleOnly%2fdefault.aspx&pgtUrl=http > > s%3a%2f%2fsso- > > > dev.foo.umd.edu%2fRestricted%2fUsersRoleOnly%2fdefault.aspx%3fproxyResp > > onse%3dtrue > > 2010-08-27 14:38:20,530 [5] DEBUG CasAuthentication - ******** > > ProcessTicketValiation - TicketValidationException (CAS server ticket > > validation threw an Exception) ************ > > 2010-08-27 14:38:20,530 [5] DEBUG CasAuthenticationModule - Starting > > AuthenticateRequest for > > /Restricted/UsersRoleOnly/default.aspx?ticket=ST-962- > > dyFiQ7ahWVR4SyjyfOzE-cas > > 2010-08-27 14:38:20,530 [5] DEBUG CasAuthenticationModule - Ending > > AuthenticateRequest for > > /Restricted/UsersRoleOnly/default.aspx?ticket=ST-962- > > dyFiQ7ahWVR4SyjyfOzE-cas > > 2010-08-27 14:38:20,530 [5] DEBUG CasAuthenticationModule - Starting > > EndRequest for /Restricted/UsersRoleOnly/default.aspx?ticket=ST-962- > > dyFiQ7ahWVR4SyjyfOzE-cas > > 2010-08-27 14:38:20,530 [5] DEBUG CasAuthenticationModule - > > Redirecting from login callback > > 2010-08-27 14:38:20,530 [5] DEBUG UrlUtil - > RemoveCasArtifactsFromUrl: > > redirectToUrl=>https://sso- > > dev.foo.umd.edu/Restricted/UsersRoleOnly/default.aspx< > > 2010-08-27 14:38:20,530 [5] DEBUG CasAuthenticationModule - Ending > > EndRequest for /Restricted/UsersRoleOnly/default.aspx?ticket=ST-962- > > dyFiQ7ahWVR4SyjyfOzE-cas > > > > > > At the same time, the CAS server says (have already authenticated at > > CAS in this scenario) > > 2010-08-27 14:38:48,184 INFO > > [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service > > ticket [ST-962-dyFiQ7ahWVR4SyjyfOzE-cas] for service [https://sso- > > dev.foo.umd.edu/Restricted/UsersRoleOnly/default.aspx] for user > > [jewhite]> > > > > Will keep digging and let you know what I come up with. There has to > be > > some explanation here ... > > > > ________________________________________ > > From: Scott M. Holodak [[email protected]] > > Sent: Friday, August 27, 2010 2:04 PM > > To: Jason Edward White; Scott M. Holodak > > Subject: RE: .Net CAS Client (w/MVC 2) > > > > Try and remove the path attribute altogether for an app at the root > of > > the web server. > > > > > -----Original Message----- > > > From: Jason Edward White [mailto:[email protected]] > > > Sent: Friday, August 27, 2010 11:48 AM > > > To: Scott M. Holodak > > > Subject: RE: .Net CAS Client (w/MVC 2) > > > > > > This worked on the VS compiled version (running on localhost) ... > I > > > get the expected sequence: > > > 1) Go to restricted area, redirect to CAS > > > 2) Authenticate > > > 3) Redirect back with ticket > > > 4) Validate ticket > > > 5) Strip and redirect w/o ticket > > > 6) View restricted page > > > > > > ... but not on the server (where path should ="/"). Actually no > > cookie > > > seems to get issued there. I'm going to go put some more debug code > > and > > > rebuild the client, but again wanted to see if you had any > immediate > > > insight. > > > > > > Thanks, > > > > > > Jason > > > ________________________________________ > > > From: Scott M. Holodak [[email protected]] > > > Sent: Thursday, August 26, 2010 5:05 PM > > > To: Jason Edward White; Scott M. Holodak > > > Subject: RE: .Net CAS Client (w/MVC 2) > > > > > > Hi, > > > > > > Check that the path property matches the URL of your web app. So > if > > > your web app is http://my.server.edu/example/, your path would be > > > "/example/". Otherwise the cookie is created for a different path > on > > > your server and it's as if it was never created at all from the > > > application's perspective. > > > > > > -Scott > > > > > > <authentication mode="Forms"> > > > <forms > > > loginUrl="https://cas.server.edu/cas/login"; > > > timeout="30" > > > defaultUrl="~/Default.aspx" > > > cookieless="UseCookies" > > > slidingExpiration="true" > > > path="/example/" /> > > > </authentication> > > > > > > > -----Original Message----- > > > > From: Jason Edward White [mailto:[email protected]] > > > > Sent: Thursday, August 26, 2010 4:59 PM > > > > To: Scott M. Holodak > > > > Subject: RE: .Net CAS Client (w/MVC 2) > > > > > > > > Scott, > > > > > > > > Thanks again for sharing and the quick reply ... I've been > toying > > > with > > > > this in the time I have. I've got it *mostly* working, but it is > > now > > > > caught in an endless redirect loop after successfully > > authenticating > > > at > > > > CAS. it's acting as if I don't have cookies set/allowed. It's as > if > > > > after setting the cookie and redirecting w/o the cas ticket, it > > > doesn't > > > > recognized the cookie. I'm going to debug with a fresh log > > tomorrow > > > > AM, but wanted to see if you had experienced anything similar to > > > this. > > > > > > > > The only config I have really changed is setting gateway to false > > and > > > > modifying the URLs. The CAS side and ticket validation seem to be > > > > working fine. > > > > > > > > Thanks again, > > > > Jason > > > > > > > > ________________________________________ > > > > From: Scott M. Holodak [[email protected]] > > > > Sent: Friday, August 20, 2010 3:34 PM > > > > To: Jason Edward White > > > > Subject: RE: .Net CAS Client (w/MVC 2) > > > > > > > > Hi Jason, > > > > > > > > I would recommend grabbing the client code directly from the SVN > > > trunk. > > > > We are planning a release shortly, but it should be stable. > > > > > > > > The basic gist of things is that the LogOn action normally > doesn't > > > have > > > > an [Authorize] attribute. It usually returns an HTML view that > > asks > > > > for > > > > a username & password. With the [Authorize] attribute, the CAS > > > > authentication module kicks in (just as it would in a web forms > > app), > > > > redirects you to the CAS server, handles the redirect back from > the > > > CAS > > > > server, gives you a FormsAuthenticationTicket/Cookie and > redirects > > > you > > > > back to the original URL (the LogOn action again). Now the LogOn > > > > action > > > > is authorized & executes. I just replaced the body with a > > > > RedirectAction that takes you back to Index/Home. The LogOff > > action > > > is > > > > pretty straightforward also. I just modified the > > > FormsService.SignOut > > > > method slightly. > > > > > > > > CASifying the default ASP.NET MVC2 project was the first thing I > > had > > > > ever done with MVC and I was pretty surprised with how easy it > was. > > > I > > > > didn't get around to checking whether the same procedures apply > to > > > the > > > > default ASP.NET MVC v1 project. If you run into any questions or > > > > roadblocks, please let me know and/or post to cas-dev. Also > please > > > > free > > > > to edit the wiki page with your notes/experiences. I'm still new > > to > > > > MVC > > > > so I don't know whether it's all best practices on the > application > > > > level. The HttpModule operates at a lower level and didn't > require > > > any > > > > significant changes to support MVC. I guess that's a good thing > :- > > ) > > > > > > > > Any feedback on/off-list or patches are greatly appreciated. > > > > > > > > Good luck! > > > > -Scott > > > > > > > > > -----Original Message----- > > > > > From: Jason Edward White [mailto:[email protected]] > > > > > Sent: Friday, August 20, 2010 3:13 PM > > > > > To: [email protected] > > > > > Subject: .Net CAS Client (w/MVC 2) > > > > > > > > > > Scott, > > > > > > > > > > We are looking to implement some .Net code with CAS. I've > looked > > > all > > > > > around and everything seems to point back to your info. on the > > > > > jasig.org site. Ours is a is MVC 2 app. I've looked over your > > > docs > > > > on > > > > > jasig.or (thanks for sharing). Do I assume correctly, that you > > > > should > > > > > use the client/s at: > > > > > > > > > > https://wiki.jasig.org/display/CASC/.Net+Cas+Client > > > > > > > > > > in conjunction with your instructions at: > > > > > > > > > > https://wiki.jasig.org/pages/viewpage.action?pageId=32210981 > ...? > > > > > > > > > > Any help greatly appreciated. And if there is someway we can > > > > > contribute, please let me know. > > > > > > > > > > Thanks, > > > > > Jason > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see http://www.ja- > sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
