Re:CAS infinite redirect loop
|
|
Mike
|
Scott,
Isn’t configuration limited to just the properties in authentication.properties listed below? Do you see anything out of place? We have a very centralized IT structure here at the UofM. I don’t have access to logs on the CAS server but do to Blackboard. Would there be any useful logs on the Bb application? I’m looking to see how to turn logging on in the CAS client. Thanks, Mike -- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user |
||||||||||||||||
|
Mike
|
Scott,
Here are a few entries from the CAS server. To me this looks like the issue is on the client as you suggest. It started the sequence with this entry: 2009-11-09 08:29:33,473 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - <AuthenticationHandler: org.jasig.cas.adaptors.ldap.FastBindLdapAuthenticationHandler successfully authenticated the user which provided the following credentials: mg123456> Reissuing of tickets from the CAS server: 2009-11-09 08:29:41,395 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service ticket [ST-4605-SjMx439ROaKpiLhBKSi4CRR473jY03nGpLg-20] for service [http://coursetest.umt.edu/webapps/login?new_loc=http%3A%2F%2Fcoursetest.umt.edu%2Fwebapps%2Fportal%2Fframeset.jsp] for user [mg123456]> 2009-11-09 08:29:41,497 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service ticket [ST-4606-YcC0dD9QHTcVelOyKXFgRme9OYcbdwEbJvp-20] for service [http://coursetest.umt.edu/webapps/login?new_loc=http%3A%2F%2Fcoursetest.umt.edu%2Fwebapps%2Fportal%2Fframeset.jsp] for user [mg123456]> 2009-11-09 08:29:43,166 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service ticket [ST-4607-iwKY4LppiQeA0gVcDAsiySpsKqUPk9y7VDi-20] for service [http://coursetest.umt.edu/webapps/login?new_loc=http%3A%2F%2Fcoursetest.umt.edu%2Fwebapps%2Fportal%2Fframeset.jsp] for user [mg123456]> 2009-11-09 08:29:43,274 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service ticket [ST-4608-AlDif9agIg5NbcRcYuuQ4wyl1rMSoermlGN-20] for service [http://coursetest.umt.edu/webapps/login?new_loc=http%3A%2F%2Fcoursetest.umt.edu%2Fwebapps%2Fportal%2Fframeset.jsp] for user [mg123456]> Thanks, Mike _________________________________ Michael Gaab Blackboard Administrator Extended Learning Services (XLS) Continuing Education The University of Montana, Missoula 406.243.6373 XLS is... UMOnline / Off-Campus Programs / Summer Semester / Wintersession / Professional Development Services |
Andrew Stutzman
|
We have had the same issue with using the phpCAS client. However, the
issue was mainly on Macs. We found that deleting your cookies often fixes the problem temporarily. The issue has been resolved on our part by limiting how many times the application checks for authentication on the CAS servers. We have very few people calling with redirect issues now. It may not be the same issue but something you can look into. Andy ---------------------------------- Andrew Stutzman Associate Director of User Support Services The College of New Jersey e: [hidden email] p: 609-771-3130 On Nov 9, 2009, at 12:39 PM, Mike wrote: > > Scott, > > Here are a few entries from the CAS server. To me this looks like > the issue > is on the client as you suggest. > > > It started the sequence with this entry: > 2009-11-09 08:29:33,473 INFO > [org.jasig.cas.authentication.AuthenticationManagerImpl] - > <AuthenticationHandler: > org.jasig.cas.adaptors.ldap.FastBindLdapAuthenticationHandler > successfully > authenticated the user which provided the following credentials: > mg123456> > > > Reissuing of tickets from the CAS server: > 2009-11-09 08:29:41,395 INFO > [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service > ticket > [ST-4605-SjMx439ROaKpiLhBKSi4CRR473jY03nGpLg-20] for service > [http://coursetest.umt.edu/webapps/login?new_loc=http%3A%2F%2Fcoursetest.umt.edu%2Fwebapps%2Fportal%2Fframeset.jsp > ] > for user [mg123456]> > 2009-11-09 08:29:41,497 INFO > [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service > ticket > [ST-4606-YcC0dD9QHTcVelOyKXFgRme9OYcbdwEbJvp-20] for service > [http://coursetest.umt.edu/webapps/login?new_loc=http%3A%2F%2Fcoursetest.umt.edu%2Fwebapps%2Fportal%2Fframeset.jsp > ] > for user [mg123456]> > 2009-11-09 08:29:43,166 INFO > [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service > ticket > [ST-4607-iwKY4LppiQeA0gVcDAsiySpsKqUPk9y7VDi-20] for service > [http://coursetest.umt.edu/webapps/login?new_loc=http%3A%2F%2Fcoursetest.umt.edu%2Fwebapps%2Fportal%2Fframeset.jsp > ] > for user [mg123456]> > 2009-11-09 08:29:43,274 INFO > [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service > ticket > [ST-4608-AlDif9agIg5NbcRcYuuQ4wyl1rMSoermlGN-20] for service > [http://coursetest.umt.edu/webapps/login?new_loc=http%3A%2F%2Fcoursetest.umt.edu%2Fwebapps%2Fportal%2Fframeset.jsp > ] > for user [mg123456]> > > > Thanks, > Mike > _________________________________ > Michael Gaab > Blackboard Administrator > Extended Learning Services (XLS) > Continuing Education > The University of Montana, Missoula > 406.243.6373 > > XLS is... > UMOnline / Off-Campus Programs / Summer Semester / Wintersession / > Professional Development Services > > -- > View this message in context: http://n4.nabble.com/Re-CAS-infinite-redirect-loop-tp584495p585032.html > Sent from the CAS Users mailing list archive at Nabble.com. > > -- > You are currently subscribed to [hidden email] as: [hidden email] > To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user |
||||||||||||||||
Scott Battaglia-2
|
In reply to this post
by Mike
You're going to have to check your CAS client logs and see why it keeps requesting new tickets. Usually its because validation failed. Either for a certificate issue or the service url doesn't match.
Cheers, Scott On Mon, Nov 9, 2009 at 12:39 PM, Mike <[hidden email]> wrote:
-- |
||||||||||||||||
YangWQ
|
(This post was updated on )
In reply to this post
by Mike
I have the same issue with using the phpCAS client and CAS cluster environment. CAS's
ticketRegistry is using memcached TicketRegistry. Can someone have some idea?
|
||||||||||||||||
Gustavo Hartmann
|
In reply to this post
by Scott Battaglia-2
Some javascript/style in this post has been disabled (why?)
Hi all, We had a similar problem last week with
phpCAS and redirection loop when we moved to a new server. In the end it came down to me debugging the CAS library by
adding “die” at various points, to stop the redirect loop so I
could see what was going on. Long story short, all it required was an extra
parameter on the phpCAS instantiation, and after that it worked fine. This has
not been required on any other server, and I don’t know if they will stop
working if we add it to them. This is what we did Change: phpCAS::client(CAS_VERSION_2_0,$domain, (int)$port, $path); To: phpCAS::client(CAS_VERSION_2_0,$domain, (int)$port, $path,
false); Not sure why it fixed the problem though. This
parameter tells phpCAS not to start new php sessions. Can someone guess? Thanks, Gustavo From:
Scott Battaglia [mailto:[hidden email]] You're going to have to
check your CAS client logs and see why it keeps requesting new tickets.
Usually its because validation failed. Either for a certificate issue or
the service url doesn't match. On Mon, Nov 9, 2009 at 12:39 PM, Mike <[hidden email]>
wrote:
-- -- |
||||||||||||||||
Marvin Addison
|
In reply to this post
by Scott Battaglia-2
> You're going to have to check your CAS client logs and see why it keeps
> requesting new tickets. Scott is right, it's the _client_ logs that will be of the most help here. Typically you don't configure logging in the CAS client per se, but in the application containing the CAS client. I have no idea whether Blackboard uses commons logging, but since blackboard-cas is a Java module, I'm hopeful Blackboard provides some instructions somewhere for configuring logging. The key logger category is org.jasig.cas.client, which you'll want to turn up to DEBUG. That should provide the information you'll need to diagnose the problem. M -- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user |
||||||||||||||||
|
Mike
|
Marvin, Thanks, I'll try to find out what how to get to the CAS logs in Blackboard. I don't think it is currently generating log files for CAS, at least not explicitly. It may be placing the log entries into another general file. Thanks again. I'm working in the dark here. Mike |
||||||||||||||||
|
Scott Battaglia-2
|
Does Blackboard use log4j? If so you should be able to add an entry in there for the CAS client using what Marvin recommended above.
Cheers, Scott On Tue, Nov 10, 2009 at 7:00 PM, Mike <[hidden email]> wrote:
-- |
||||||||||||||||
|
YangWQ
|
(This post was updated on )
The problem has been resolved in my CAS cluster environment.
When I check the logs of phpCAS and cas, and found that the ticket is expired when one cas server validated it. I checked the time of the cluter meachines' operating systems,found the time is different from one another. The i modified to the same time, cas is working well now.
|
||||||||||||||||
Dallas
|
In reply to this post
by Marvin Addison
Hi guys, apologies for stepping into the middle of this thread but I'm running into the same issue.
When running my service app behind a load balancer I'm getting into an infinite redirect loop when authenticating against CAS, but when I run the exact same service application in a dev env (my laptop) it works great, no loop. In both cases the service app is pointing at the same CAS server. I've turned on debug on the service app for the cas client, a sample of the log from the load balanced env is given below, it appears to me that the initial authentication request and validation is processed successfully but after that it looks like it keeps trying to authenticate again. I'm not seeing anything in this log file that indicates, at least to me, why the client is trying to redirect to the CAS server. I'm using CAS server 3.3.2 (using a database backed service registry to persist whitelist service apps) CAS client 3.1.6 rg/products/cas/"><AttributeValue>CB426F04962141E2AF680D178062247R</AttributeValue></Attribute><Attribute AttributeName="groups" AttributeNamespace="http://www.ja-sig.org/products/cas/"><AttributeValue>TGP</AttributeValue></Attribute></AttributeStatement><AuthenticationStatement AuthenticationInstant="2009-11-20T23:10:55.261Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified"><Subject><NameIdentifier>j.black@test.com</NameIdentifier><SubjectConfirmation><ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:artifact</ConfirmationMethod></SubjectConfirmation></Subject></AuthenticationStatement></Assertion></Response></SOAP-ENV:Body></SOAP-ENV:Envelope> DEBUG [2009-11-20 17:11:07] [http-10.28.121.133:8080-10$2042324462] org.jasig.cas.client.validation.Saml11TicketValidationFilter : Successfully authenticated user: j.black@test.com DEBUG [2009-11-20 17:11:07] [http-10.28.121.133:8080-10$2042324462] org.jasig.cas.client.validation.Saml11TicketValidationFilter : Redirecting after successful ticket validation. DEBUG [2009-11-20 17:11:07] [http-10.28.121.133:8080-10$2042324462] org.jasig.cas.client.util.CommonUtils : serviceUrl generated: http://test.trumpet.com/attractions/report-abuse/restaurants/texas/austin-area/austin/region:7116/1fa2c62f-8082-0810-e693-98e2a220bf08 DEBUG [2009-11-20 17:11:15] [http-10.28.121.133:8080-3$1990261195] org.jasig.cas.client.util.CommonUtils : serviceUrl generated: http://test.trumpet.com/attractions/report-abuse/restaurants/texas/austin-area/austin/region:7116/1fa2c62f-8082-0810-e693-98e2a220bf08 DEBUG [2009-11-20 17:11:15] [http-10.28.121.133:8080-3$1990261195] org.jasig.cas.client.authentication.AuthenticationFilter : no ticket and no assertion found DEBUG [2009-11-20 17:11:15] [http-10.28.121.133:8080-3$1990261195] org.jasig.cas.client.authentication.AuthenticationFilter : Constructed service url: http://test.trumpet.com/attractions/report-abuse/restaurants/texas/austin-area/austin/region:7116/1fa2c62f-8082-0810-e693-98e2a220bf08 DEBUG [2009-11-20 17:11:15] [http-10.28.121.133:8080-3$1990261195] org.jasig.cas.client.authentication.AuthenticationFilter : redirecting to "https://cas-test.trumpet.com/login?service=http%3A%2F%2Ftest.trumpet.com%2Fattractions%2Freport-abuse%2Frestaurants%2Ftexas%2Faustin-area%2Faustin%2Fregion%3A7116%2F1fa2c62f-8082-0810-e693-98e2a220bf08" DEBUG [2009-11-20 17:11:15] [http-10.28.121.133:8080-3$533440100] org.jasig.cas.client.util.CommonUtils : serviceUrl generated: http://test.trumpet.com/attractions/report-abuse/restaurants/texas/austin-area/austin/region:7116/1fa2c62f-8082-0810-e693-98e2a220bf08 DEBUG [2009-11-20 17:11:15] [http-10.28.121.133:8080-3$533440100] org.jasig.cas.client.authentication.AuthenticationFilter : no ticket and no assertion found DEBUG [2009-11-20 17:11:15] [http-10.28.121.133:8080-3$533440100] org.jasig.cas.client.authentication.AuthenticationFilter : Constructed service url: http://test.trumpet.com/attractions/report-abuse/restaurants/texas/austin-area/austin/region:7116/1fa2c62f-8082-0810-e693-98e2a220bf08 DEBUG [2009-11-20 17:11:15] [http-10.28.121.133:8080-3$533440100] org.jasig.cas.client.authentication.AuthenticationFilter : redirecting to "https://cas-test.trumpet.com/login?service=http%3A%2F%2Ftest.trumpet.com%2Fattractions%2Freport-abuse%2Frestaurants%2Ftexas%2Faustin-area%2Faustin%2Fregion%3A7116%2F1fa2c62f-8082-0810-e693-98e2a220bf08" DEBUG [2009-11-20 17:11:15] [http-10.28.121.133:8080-3$1990261195] org.jasig.cas.client.util.CommonUtils : serviceUrl generated: http://test.trumpet.com/attractions/report-abuse/restaurants/texas/austin-area/austin/region:7116/1fa2c62f-8082-0810-e693-98e2a220bf08 DEBUG [2009-11-20 17:11:15] [http-10.28.121.133:8080-3$1990261195] org.jasig.cas.client.authentication.AuthenticationFilter : no ticket and no assertion found
|
||||||||||||||||
|
Scott Battaglia-2
|
You should (a) make sure you're always hitting the same server and (b) a session is being created and stored. If you're in a load-balanced environment those are generally the major issues (unless you've clustered your sessions).
Cheers, Scott On Fri, Nov 20, 2009 at 6:46 PM, Dallas <[hidden email]> wrote:
-- |
||||||||||||||||
|
Dallas
|
Ok..., I can do that.
But I'm curious, your reply implies that the CAS client is storing something in the service app session. I was under the impression that the CAS protocol does not rely on session state. Can you point me at any documentation that describes what the CAS client is doing with the session or can you provide a brief description?
|
||||||||||||||||
|
Marvin Addison
|
> I was under the impression that the CAS protocol
> does not rely on session state. You are correct, the CAS protocol can work without storing any state in the client application. However, it will produce a round-trip to the server on every request to the client otherwise. For this reason almost all clients store some kind of session-based data. I see you're using the SAML ticket validator. Session state is more important in that case since you likely want the attributes released from the server to perform, for example, authorization at the client. The CAS assertion containing the authenticated principal and attributes from the server are stored as session data. (The assertion can also be stored as thread-local data for sessionless operation, but session-based data is much more common.) M -- You are currently subscribed to [hidden email] as: [hidden email] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
