On 5/21/07, Lucas Rockwell <[EMAIL PROTECTED]> wrote:
Hi all,
Using the email below (and other information from around the web), I
was able to implement CAS clustering on two different hosts. Things
are running, but I still have some questions and I hope someone can
clarify them for me.
Background: I am clustering the login flow using Tomcat session
replication, and the tickets are being replicated using the
JBossCacheTicketRegistry. Both seem to be working fine.
Glad to hear its working! If you get a moment and you can add anything to
our existing JBossCacheTicketRegistry documentation in wiki that would be
great!
My first question: If I am using the JBossCacheTicketRegistry, do I
have to implement a custom RegistryCleaner (which is alluded to here:
http://www.ja-sig.org/products/cas/server/cluster/index.html)?
You would most likely just want to ensure the default registry is only
running on one of the machines in the cluster (as cleaning on one should be
propagated to the others).
My second question (actually 2 questions): I have set up unique
tickets for users that are generated on each host (TGTs), but do I
have to worry about service tickets? In other words, I am passing a
unique (one per host) value to the value attribute of the
ticketGrantingTicketUniqueIdGenerator bean. Should I be doing the
same thing for the service tickets (the
serviceTicketUniqueIdGenerator bean)?
You should set one also for the Service Tickets since they are also being
clustered.
I also see this error in the logs, and it has me a little worried:
2007-05-21 14:05:35,594 INFO
[org.jasig.cas.ticket.proxy.support.Cas20ProxyHandler] - <No
UniqueTicketIdGenerator specified for
org.jasig.cas.ticket.proxy.support.Cas20ProxyHandler. Using
org.jasig.cas.util.DefaultUniqueTicketIdGenerator>
This actually isn't an error, just an informational message. By default,
CAS assumes non-clustered, and will help instantiate some things so you
don't have to. You'll merely want to define a TicketIdGenerator for the
Cas20ProxyHandler.
So, the same for the above, should I set this to (via the bean
property) to the serviceTicketUniqueIdGenerator bean (which uses
DefaultUniqueTicketIdGenerator)?
This is how I am doing uniqueness for
ticketGrantingTicketUniqueIdGenerator:
<bean id="placeholderConfig"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfi
gurer">
<property name="locations">
<list>
<value>file:/apps/local/share/etc/host.properties</
value> <!-- The values in this file are unique to the host on which
it resides. -->
</list>
</property>
</bean>
<!-- ID Generators -->
<bean
id="ticketGrantingTicketUniqueIdGenerator"
class="org.jasig.cas.util.DefaultUniqueTicketIdGenerator">
<constructor-arg
index="0"
value="${host.name}" />
</bean>
Basically, I am appending the hostname to the end of the TGTs. This
also allows us to know from which server a user initially logged in
just by looking at the ticket.
Please let me know if something looks askew.
That looks fine!
-Scott
Many thanks.
-lucas
On Jan 16, 2006, at 10:58 AM, Scott Battaglia wrote:
> iztok wrote:
>> on sticky sessions. why are they needed?
> CAS3 maintains the state of your login flow in the FlowScope of the
> login flow. The default storage location of this is the session.
> So if
> you have multiple CAS machines and you're not replicating session
> state
> across machines (or have reimplemented the FlowStorage) then you
> need to
> make sure the client goes back to the same machine that has his or her
> state.
>> if in a clustered environment, both CAS server1 and server2 have the
>> same state, presumably they will each make the same decision if
>> asked?
>>
> Yes, you just have to make sure they have the same state :-) And
> depending on your set up there are potentially a few things to change
> (see above)
>> we are not so much interested in load balancing but more in
>> availability. so we do not care too much if the users are imperfectly
>> load balanced but we do care about is users be able to use another
>> cas
>> server seamlesly if the one they got their TGC or ST on implodes.
>>
>> <snip />
>>
>> i guess we need to ensure that if i get my TGC from server1, and
>> subsequently obtain my ST from server2, my app can still validate the
>> ST against server3 .... is that possible?
>>
> It most certainly is! You'll need to replace the default
> TicketRegistry
> with one that shares data (we have a simple JDBC one in the CAS-
> Modules
> project but you may need a more complex one). Depending on your
> clustering/failover needs/setup you may also need to swap out the
> default FlowStorage with one that doesn't use the session. I would
> also
> recommend grabbing the DefaultUniqueTicketIdGenerator which allows you
> to append a suffix so that if properly configured you can assure
> uniqueness across JVMs of Ticket Id generation.
> -Scott
>> _______________________________________________
>> Yale CAS mailing list
>> [email protected]
>> http://tp.its.yale.edu/mailman/listinfo/cas
>>
> _______________________________________________
> Yale CAS mailing list
> [email protected]
> http://tp.its.yale.edu/mailman/listinfo/cas
>
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
--
-Scott Battaglia
LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
