Hi Scott, I think I finally understand what is going on here (took me a while) and yet I need your help to make it work :)
As I mentions, I have configured mod_cas_auth to communicate with a Load balancer that is in front of two cas servers with a jpa ticket registration over mysql. Here is part of /etc/apache2/httpd.conf: CASLoginURL https://loginloadbalancer.domain.com:8443/cas/login CASValidateURL https:/// loginloadbalancer.domain.com:8443/cas/serviceValidate By monitoring cas.log, I figured that the load balancer sticky session function does work properly and forwards request to the same cas server, lets say cas01 for instance. So on Cas01, the cas.log shows that authentication process goes over the the right steps all the way to: -- INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - Granted service ticket [ST-6-IQ7rJwKqtxsADsydfsd9R-*Cas01-full-domain-address.com*] for service [http://myapp.mydomain.com/app1] for user [test] INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN ============================================================= WHO: test WHAT: ST-6-IQ7rJwKqtxsADsydfsd9R-*Cas01-full-domain-address.com* for http://myapp.mydomain.com/app1 *ACTION: SERVICE_TICKET_CREATED* -- Now, the last action that is requered is 'ACTION: SERVICE_TICKET_VALIDATED' and I am in! Right? well this log event *does not* appears on Cas01! It appears on *Cas02 *and declaring a failure: -- INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - ServiceTicket [ST-6-IQ7rJwKqtxsADsydfsd9R-*Cas01-full-domain-address.com*] *has expired.* INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN ============================================================= *WHO: audit:unknown* WHAT: ST-6-IQ7rJwKqtxsADsydfsd9R-*Cas01-full-domain-address.com* ACTION: *SERVICE_TICKET_VALIDATE_FAILED* -- So I figured that if mod_cas_auth is configured this way: CASLoginURL https://loginloadbalancer.domain.com:8443/cas/login CAS*Validate*URL https:/// loginloadbalancer.domain.com:8443/cas/serviceValidate It means that the login phase will we forwarded towards the Load balancer and the user will be redirected always to the same Cas because of the stickiness of the session (towards Cas01 in the mentions case) . The thing is that I suspect that the last phase of CAS*Validate*URL is initiated by the Apache server itself (and not by the client), so again it goes to the load balancer, but this time it is a different session and it is being redirects to the other cas (Cas02 in the mentions case), and that other cas (cas02) does not aware of something to have is successful validated and declares that the ST is expired. I currently dont know how to solve it. I did try raising the number of times that a ticket can be used before its considered expired within ticketExpirationPolicies.xml (I set it from 1 to 20 - just to give it a try) and yet it does not help, more over it seems like the ST is being immediately deleted from the mysql db regardless of my setting. By the way, when I set cas_mod_auth with the following configurations (basically making both process to work with the same cas), it works perfectly which kind of supports my claims: CASLoginURL https://loginloadbalancer.domain.com:8443/cas/login CAS*Validate*URL https:///*Cas01-full-domain-address.com* :8443/cas/serviceValidate or CASLoginURL https://*Cas01-full-domain-address.com*:8443/cas/login CAS*Validate*URL https:///*Cas01-full-domain-address.com* :8443/cas/serviceValidate or CASLoginURL https://*Cas02-full-domain-address.com*:8443/cas/login CAS*Validate*URL https:///*Cas02-full-domain-address.com* :8443/cas/serviceValidate Any ideas?? Shouldn't the ticketExpirationPolicies.xml solve it ?? why is it being deleted from the db regardless of my settings? Thanks!!! On Tue, Jun 12, 2012 at 4:03 PM, Ronen Itkin <[email protected]> wrote: > :) > I will try. > > > On Tue, Jun 12, 2012 at 3:54 PM, Scott Battaglia < > [email protected]> wrote: > >> Sorry, I misread what you wrote as replication (its early here :-)). If >> you have sticky sessions enabled, can you confirm that they are really >> hitting the same server? >> >> >> On Tue, Jun 12, 2012 at 8:39 AM, Ronen Itkin <[email protected]> wrote: >> >>> What do you mean replicated in this case? >>> >>> >>> >>> On Tue, Jun 12, 2012 at 3:26 PM, Scott Battaglia < >>> [email protected]> wrote: >>> >>>> Ronen, >>>> >>>> Do you know if the session is replicating quickly enough? (I don't >>>> actually know the best way to test this :-)) >>>> >>>> Cheers, >>>> Scott >>>> >>>> >>>> On Tue, Jun 12, 2012 at 8:18 AM, Ronen Itkin <[email protected]> wrote: >>>> >>>>> Scott - Actually I enabled a 'sticky session' option on the load >>>>> balancer - so as long as the session was not terminated by the cas server >>>>> itself, it should be always redirected to the same as. >>>>> >>>>> by the way when the load balancer has only one cas server in service >>>>> it works great! >>>>> When I add another cas server to the load balancer, those issues >>>>> arises. >>>>> So is has to be something with the lb redirection - but what? :/ >>>>> >>>>> Leszek - Thanks! I dont want to give up on load sharing (yet :)). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Jun 12, 2012 at 2:51 PM, Scott Battaglia < >>>>> [email protected]> wrote: >>>>> >>>>>> Spring Web Flow doesn't allow you to round robin your CAS requests >>>>>> unless you're using Tomcat session replication. Spring Web Flow holds >>>>>> its >>>>>> internal state in session (though you could write something that replaces >>>>>> that). >>>>>> >>>>>> Cheers, >>>>>> Scott >>>>>> >>>>>> >>>>>> On Tue, Jun 12, 2012 at 6:30 AM, Ronen Itkin <[email protected]>wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> I have implemented two cas 3.4.12 servers with jdbc support and JPA >>>>>>> ticket registration. >>>>>>> It worked great until I added a load balancer that redirects traffic >>>>>>> to one of the available cas servers (based on port availability - round >>>>>>> robin session redirection), >>>>>>> Actually it is Amazon's web services load balancer, AKA Elastic Load >>>>>>> Balancer. >>>>>>> It listens to port 8443 and forwards it to the same port (8443) >>>>>>> towards one on the available cas servers. >>>>>>> Cas login page appears and when I am trying to log in it just >>>>>>> reloads the cas login screen again - without mentioning any problems, it >>>>>>> repeats itself for a few login tries and after few attempts I get the >>>>>>> following notification from my browser: >>>>>>> >>>>>>> --- >>>>>>> Authorization Required >>>>>>> >>>>>>> This server could not verify that you are authorized to access the >>>>>>> document requested. Either you supplied the wrong credentials (e.g., bad >>>>>>> password), or your browser doesn't understand how to supply the >>>>>>> credentials >>>>>>> required. >>>>>>> ------------------------------ >>>>>>> Apache/2.2.16 (Ubuntu) Server at x.x.x.x.. >>>>>>> x.x.compute-1.amazonaws.com Port 80 >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> >>>>>>> *Cas.log shows:* >>>>>>> >>>>>>> >>>>>>> 2012-06-12 10:11:22,848 INFO >>>>>>> [org.jasig.cas.CentralAuthenticationServiceImpl] - ServiceTicket [ >>>>>>> ST-1-SCiu0IAOcYwAcMd3ElRi-ec2-xx-xx-xxx-xxx.compute-1.amazonaws.com] >>>>>>> has expired. >>>>>>> 2012-06-12 10:11:22,851 INFO >>>>>>> [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - >>>>>>> Audit >>>>>>> trail record BEGIN >>>>>>> ============================================================= >>>>>>> *WHO: audit:unknown* >>>>>>> WHAT: >>>>>>> ST-1-SCiu0IAOcYwAcMd3ElRi-ec2-xx-xx-xxx-xxx.compute-1.amazonaws.com >>>>>>> ACTION: SERVICE_TICKET_VALIDATE_FAILED >>>>>>> APPLICATION: CAS >>>>>>> WHEN: Tue Jun 12 10:11:22 UTC 2012 >>>>>>> CLIENT IP ADDRESS: 10.210.218.98 >>>>>>> SERVER IP ADDRESS: 10.211.173.168 >>>>>>> ============================================================= >>>>>>> >>>>>>> So I guess it acts that way because it cant recognize the user that >>>>>>> is attempting to login because normally is should write: >>>>>>> >>>>>>> WHO: [username: ronen] >>>>>>> >>>>>>> Does someone has an Idea of why it can happen while accessing Cas >>>>>>> trough a load balancer? >>>>>>> If I am accessing both cas servers directly and try to simply >>>>>>> authenticate it works great!! only when accessing cas trough the load >>>>>>> balancer it happens occasionally. >>>>>>> (It does work sometimes - means that the ssl certificate of Cas's >>>>>>> tomcat machine was successfully imported to the load balancer and basic >>>>>>> configurations are fine) >>>>>>> >>>>>>> >>>>>>> Thanks!! >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> * >>>>>>> Ronen Itkin* >>>>>>> Taykey | www.taykey.com >>>>>>> >>>>>>> -- >>>>>>> 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-user >>>>>>> >>>>>>> >>>>>> -- >>>>>> 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-user >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> * >>>>> Ronen Itkin* >>>>> Taykey | www.taykey.com >>>>> >>>>> -- >>>>> 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-user >>>>> >>>>> >>>> -- >>>> 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-user >>>> >>>> >>> >>> >>> -- >>> * >>> Ronen Itkin* >>> Taykey | www.taykey.com >>> >>> -- >>> 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-user >>> >>> >> -- >> 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-user >> >> > > > -- > * > Ronen Itkin* > Taykey | www.taykey.com > > -- * Ronen Itkin* Taykey | www.taykey.com -- 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-user
