Christian,
I'm just taking a blind stab at it, but looking at the "Web Sessions Express
Installation" documentation, it seems that the express (non DSO) configuration
may conflict with the example configuration provided that contains a DSO
dependent configuration.
I had a similar issue until I ditched the "express configuration" and placed a
specific web-application configuration into my tc-config.xml:
<application>
<dso>
<web-applications>
<web-application>cas</web-application>
</web-applications>
</dso>
</application>
Of course, this opens a potential pandor... I mean "terracotta's box" for other
configuration options. You can refer to my earlier mailings and ticket posting
for more information: https://issues.jasig.org/browse/CAS-750
I am also curious as to why you are running on only one terracotta server, as
from how I understand how the product works, that if your machine running the
server goes down, then your other machine's client will hang. Since this has
been my experience in testing, we run a terracotta server on each physical node
of CAS.
Raymond Walker
Software Systems Engineer Sr.
ITS Northern Arizona University
On Aug 12, 2010, at 12:41 AM, Christian Lambertz wrote:
> We are trying to implement CAS with Terracotta-replication in a test
> environment. Our configuration:
>
> servers:
> running all Windows Server 2003
> one server: Apache 2.2.15, OpenSSL, mod_jk (sticky sessions) loadbalancing
> with Tomcat Servers
> two servers: Tomcat 6.0.26, CAS 3.3.5, one of these with Terracotta 3.2.1_2
>
> Configurations changes Tomcat:
> Insert into tomcat/conf/context.xml the following line:
> <Valve className="org.terracotta.session.TerracottaTomcat60xSessionValve"
> tcConfigUrl="172.16.1.202:9510"> </Valve>
> according to Terracotta documentation "Web Sessions Express Installation"
> where 172.16.1.202 is our Terracotta server.
>
> Configuration changes to CAS:
> We changed deployerConfigContext.xml to meet our ldap-configuration
> We changed the log configuration
> Nothing more.
>
> Configuration changes to Terracotta:
> Using a tc-config.xml-sample send by Scott Battaglia (thanks for that), see
> attachment. We only made path adjustments to this file.
>
> Result:
> All systems start normally, logfiles are looking OK.
>
> Test 1:
> Using our CAS-Login-URL (https://cas.uni-goettingen.de):
> With both CAS-Servers/Terracotta-Clients
> With one CAS-Server/Terracotta-Client deactivated while the test is running
> Result: Once you are successfully authenticated and received a TGT, you stay
> authenticated regardless which CAS-Server/Terracotta-Client is actually
> running. Session stickyness between Apache and Tomcat is used and works.
> So we assume, that TGTs are successfully replicated between our
> CAS-Servers/Terracotta-Clients
>
> Test 2:
> Using a web application which redirects its login to CAS and uses the
> serviceValidate-function of CAS.
> It works as follows (assuming you have a valid TGT):
> 1. Web-application redirects Browser to CAS (sticky session)
> 2. CAS retrieves TGT from registry successfully
> 3. CAS adds a ST-Ticket to registry and delivers it back to web application
> with success
> 4. Web application starts a cas/serviceValidate on its own with ST-Ticket (no
> sticky session here). This goes to the other CAS-Server, which could not find
> the ST-Ticket in its registry.
> 5. Result: Authentication failed. We assume, that ST-Tickets are not
> replicated by our Terracotta-configuration. The attached log shows the
> problem very plainly.
>
> Has anybody experienced the same problem and probably a solution?
> I would very much appreciate any usefull reaction.
>
> Thanks in advance
> Christian
>
>
> --
> 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<sample-terracotta-config.xml><log_st.txt>
--
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
