Hi Scott, I guess another option will be using an Active-Standby load balancer and not an Active-Active like mine, Unfortunately the Elastic Load Balancer of Amazon does not support this mode. Another option is to use the load balancer with one node only and define Auto-Scaling group driven my a CloudWatch alert (Amazon Monitoring system), same as for scale back down to one node.
Anyway, regarding your suggestion, can you please elaborate more on how will it solve the problem? What exactly is missing for on the second cas (cas02) to be able to validate the client that was processed by cas01? Isnt it the advantage/purpose of using JPA ticket registry (on top a db) is to have it all saved in a centralized place where every cas server can reach, if one cas goes down, the second can authenticate the TGT saved on the data base? I guess I dont fully understand the authentication process.. as I see it, everything should be saved in the db (in this specific registration method I use of-course ) and all Cas servers should reach this db and have all needed information in order to authenticate a client. Wouldnt it be exactly like using EhCache or Memcached inorder to share this information between Cas servers? I mean.. Instead of using a shared db (like in my case), it will share memory - but what is saved on Cas01 memory that is not being saved on the db and that cas02 cant reach ? If there is something like that, then it kind of conflicts with the HA JPA ticket registration purpose, isnt it? Again, Thanks a lot :) !! On Tue, Jul 24, 2012 at 5:47 AM, Scott Battaglia <[email protected]>wrote: > You are correct, the call to validate is initiated in its own session, > thus sticky session will not work. > > Your only option is to have a distributed memory store, either via EhCache > or Memcached (there is a database backed version also, but EhCache or > Memcached are probably fine/better for you). > > Cheers, > Scott > > > On Mon, Jul 23, 2012 at 8:49 AM, Ronen Itkin <[email protected]> wrote: > >> 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 >> >> > -- > 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
