In my LB based on Apache I'm using configuration below:
<Proxy balancer://cas>
BalancerMember https://IP:8443 route=cas1
BalancerMember https://IP:8443 route=cas2 status=+H
ProxySet nofailover=On
</Proxy>
Requests will be send to cas2 only when cas1 is unavailable. For this setup I
dont need Tomcat session replication. But of course it's only HA.
Leszek Miś
Owner & System Architect
Red Hat Certified Architect & Security Specialist
tel: 791-611-309
Emerge Systems
http://www.emerge.pl
----- Oryginalna wiadomość -----
Od: "Scott Battaglia" <[email protected]>
Do: [email protected]
Wysłane: wtorek, 12 czerwiec 2012 13:51:21
Temat: Re: [cas-user] Cas 3.4.12 HA implementation using Amazon elastic load
balancer
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
--
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
