I did some testing with my account and it definitely seems like a bug in the SAML ticket validator. If the user attempting to login doesn't have any of the attributes being released to that service, the .NET client seems to be throwing out the SAML response and redirects the user back to the CAS server. The CAS server issues a new SAML response and sends them back to the service where the .NET client throws away the response...and we're in a redirect loop.
I tested it by releasing one attribute and successfully logging into the service. I then deleted that attribute from my LDAP entry, attempted to login and received the redirect error. It seems like the SAML that is being generated is valid, it just doesn't have any AttributeStatement nodes. Should I put in a JIRA ticket on this? -- Eric Pierce Identity Management Architect Information Technology University of South Florida (813) 974-8868 -- epie...@usf.edu ________________________________ From: Lehman, Jason <jleh...@usf.edu> Sent: Tuesday, November 05, 2013 3:58 PM To: cas-dev@lists.jasig.org Subject: RE: [cas-dev] CAS .NET Client Redirect Loop and Attributes In regards to using http:// vs https:// we have been having an issue there too but I was going to bring that up separately. We are having an issue where we are not being directed back to https://servername but instead being directed back to http://servername:443. I have attached the logs for a session where this occurred. The web.config is also attached. From: Scott [mailto:scottt...@gmail.com] Sent: Tuesday, November 05, 2013 2:44 PM To: cas-dev@lists.jasig.org Subject: Re: [cas-dev] CAS .NET Client Redirect Loop and Attributes I'm not too familiar with the Saml11TicketValidator implementation so I can't easily spot whether you could have an issue there by looking at the logs. You may want to try adjusting the ticketTimeTolerance. It may be worth experimenting with ticketValidatorName="Cas20". I believe there were some patches to the CAS 2.0 validator to accept attributes. You alluded to there being more than one server in the data center. Do you have multiple web servers running the application that you're attempting to CASify? If so, your situation gets slightly complicated. From the looks of it, on line 53 it's 'Processing Proxy Callback request'. Proxy authentication won't succeed without a proxyTicketManagerProvider registered and the default proxyTicketManager and serviceTicketManager don't support multiple web servers. Processes that depend on those services will inevitably fail (proxy ticket creation, processing of inbound single-signout requests) unless you plug in your own custom implementation of IServiceTicketManager and IProxyTicketManager that persist to shared storage. I see that you have removed the proxyTicketManagerProvider from web.config. If line 53 means that it's trying to use that provider, that could explain why the ticket/cookie isn't getting generated. If you aren't running your app on multiple servers, try to remove the serviceTicketManagerProvider="CacheServiceTicketManager" attribute. Your serverName attributes shows http://. I'm not sure offhand whether the CAS server has restrictions on connecting to http:// endpoints by default, but https:// is definitely recommended for security purposes, particularly when proxy tickets are in play. If there is a restriction on this, the proxy ticket phase could be failing due to a missing callback from the CAS server. I imagine the logs on the CAS server would indicate this situation. The last resort troubleshooting approach on the app side would be to try would be to include the DotNetCasClient as a project reference rather than an assembly reference. You could then set breakpoints in CasAuthentication or CasAuthenticationModule and see what's going on under the hood. -Scott On Tue, Nov 5, 2013 at 12:22 PM, Lehman, Jason <jleh...@usf.edu<mailto:jleh...@usf.edu>> wrote: Worked with the Data Center and the certificate wasn’t installed on every server but that has been resolved. Still getting the redirect loop when there is successful authentication with a user who does not have attributes I am looking for but no redirect when user has attributes. I have attached the CAS client log file. In the log file are the two attempts. The login with a user without the attributes is the first part of the file going from line 1 to line 244. The login with a user with the attributes starts at line 245. Let me know if I need to adjust the web.config log configuration in any way to give more info. From: Scott [mailto:scottt...@gmail.com<mailto:scottt...@gmail.com>] Sent: Tuesday, November 05, 2013 10:15 AM To: cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org> Subject: Re: [cas-dev] CAS .NET Client Redirect Loop and Attributes I just looked over your HTTP logs again and noticed a few things I must have missed the other day. 1) there is no redirect from the CAS server to your application with a service ticket parameter. The CAS client expects the redirect back from CAS to have that. 2) there is no ASPXAUTH cookie getting sent back to the browser. When the CAS client successfully validates the ticket, it uses standard Forms Authentication methods to create a FormsAuthenticationTicket and serializes it into a cookie (named ASPXAUTH by default I think) Not sure why your logs don't show what looks like a successful authentication at the CAS server, which would explain why the FormsAuth ticket never gets created (the ST is validated and then a ticket/cookie is created). If there were an ST coming back, but no ASPXAUTH cookie getting created, 99% of the time that would be because of a validation failure, which is generally bad configuration (wrong IP/host name) or an untrusted cert. -Scott On Mon, Nov 4, 2013 at 6:42 PM, Scott <scottt...@gmail.com<mailto:scottt...@gmail.com>> wrote: Try turning on the tracing built in to the .NET client and post those logs back. Assuming it's not a cookie problem, it should shed some more insight into why it's redirecting back out to the CAS server. I might have mislead you with the IE/Chrome test. I'm not 100% sure that would confirm it. If your CAS server's SSL certificate is valid, not expired, and issued by a > $7/yr CA, this is probably barking up the wrong tree. But if you're using one of the cheaper CA's, a self-signed cert, or an enterprise CA, this is a very common cause for redirect issues. The comments in the example web.config show how to turn the tracing on. Be sure to grant whatever identity your app pool is running as write permissions to the log file. https://github.com/Jasig/dotnet-cas-client/blob/master/ExampleWebSite/web.config.sample On Mon, Nov 4, 2013 at 12:29 PM, Lehman, Jason <jleh...@usf.edu<mailto:jleh...@usf.edu>> wrote: 1) This doesn’t seem to be the issue because I went to the server using IE and Chrome and I didn’t receive a certificate error. 2) Removing the path didn’t stop the loop when using credentials without the attributes but login in with credentials with the attributes worked fine. 3) As soon as I removed the serviceTicketManager and singleSignout=”true” .NET thru up an error saying that was a required attribute for single signout. So instead I set singleSignout=”false” and removed serviceTicketManager and the redirect still occurs when using credentials that don’t have the attribute assigned but works fine for credentials that do have the attribute. Anything else I should try? Thanks for the help. From: Scott [mailto:scottt...@gmail.com<mailto:scottt...@gmail.com>] Sent: Monday, November 04, 2013 11:44 AM To: cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org> Subject: Re: [cas-dev] CAS .NET Client Redirect Loop and Attributes Here are a few things to change to see if it eliminates the problem. All three of them can cause redirect loops. If you end up having to turn off a feature that you want to use in order to resolve the problem, post back to the list and I'll be happy to help you configure it properly. 1) Verify that the SSL certificate installed on your CAS server is trusted by Windows. If IE or Chrome shows a security warning when you browse to your CAS server, the HTTP client connection that happens as part of the service ticket validation will also fail. Similarly, if the CAS server doesn't trust the SSL certificate on your web server, proxy ticket support won't be possible. 2) Try removing the following from authentication/forms in web.config: path="/iUSF/". Restricting the cookie path is a good idea when your web server is hosting more than 1 application and you want them to be isolated wrt. authentication, but if configured incorrectly, it will result in a redirect loop as well. 3) Try removing the following from casAuthentication in web.config: singleSignout="true", serviceTicketManager="CacheServiceTicketManager". This is particularly important if you have more than one web server in your application. CacheServiceTicketManager isn't suitable for multiple web servers. When it's enabled, it stores information about the outstanding valid tickets in memory on the web server. If the ticket was validated on one server but a subsequent request was handled by another, the validation would fail (the cookie details won't be in memory on that server and the cookie will be ignored). You could end up in a redirect loop there as well. To get around this, you could implement your own IServiceTicketManager with a sql/memcached/redis back-end that all your servers share access to. -Scott On Mon, Nov 4, 2013 at 10:38 AM, Lehman, Jason <jleh...@usf.edu<mailto:jleh...@usf.edu>> wrote: I have attached the requested files. -----Original Message----- From: Marvin Addison [mailto:marvin.addi...@gmail.com<mailto:marvin.addi...@gmail.com>] Sent: Monday, November 04, 2013 9:34 AM To: cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org> Subject: Re: [cas-dev] CAS .NET Client Redirect Loop and Attributes > If I login with a user that doesn't have an attribute I'm expecting > using the CAS .NET client I get into a redirect loop. Please post your config and an HTTP header trace from an authentication attempt. That should help clarify whether it's a bug, configuration matter, or a mix of bad behavior in the face of configuration for which we might want to file an improvement issue. M -- You are currently subscribed to cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org> as: jleh...@usf.edu<mailto:jleh...@usf.edu> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org> as: scottt...@gmail.com<mailto:scottt...@gmail.com> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org> as: jleh...@usf.edu<mailto:jleh...@usf.edu> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org> as: scottt...@gmail.com<mailto:scottt...@gmail.com> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org> as: jleh...@usf.edu<mailto:jleh...@usf.edu> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org> as: scottt...@gmail.com<mailto:scottt...@gmail.com> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org> as: jleh...@usf.edu<mailto:jleh...@usf.edu> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org<mailto:cas-dev@lists.jasig.org> as: epie...@usf.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
