Just a caution -- do not parse the hostname from the URL, and use as-is for validation. This will lead to a simple compromise, where Mallory simply passes ticket=ST-12345:my.evilcas.com , which will immediatley validate all tickets as "superduperadmin". However, a key could be passed to lookup from a local mapping table.
Just my $0.02, -Matt On Thu, Jan 15, 2009 at 4:57 PM, Lucas Rockwell <l...@berkeley.edu> wrote: > Hello CAS developers, > > I have an idea about how to make CAS highly available (HA) without > doing Service Ticket/Proxy (Granting) Ticket (ST and PT) replication, > so I would like to propose it to you all and see what you think. > > First, let me start off by saying that I think it is still wise to > replicate TGTs, especially considering replicating TGTs can withstand > very high latencies (several seconds or more). Actually, the latency > tolerance for TGTs is such that you could even replicate them in LDAP > if you wanted to (which does replication very well, and securely). > > So, my proposal for "replicating" STs and PTs is as follows: Make each > CAS server aware of its peers, and use the CAS protocol itself for > validating tickets. I will try to clarify this with an example: > > The simplest scenario is 2 CAS servers -- CAS1 and CAS2 -- (but this > scales to n CAS servers). Each CAS server has a list of all the CAS > servers in the cluster (using "cluster" for lack of a better term), > including itself. When a CAS server (CAS1) receives a ST or PT for > validation, it simply looks at the ticket to determine where the > ticket originated (this is done by inspecting the end of the ticket > value which will have the hostname of the originating CAS server > appended to it -- just as tickets do now). If the ticket originated > with itself (CAS1), it handles the validation like normal. If the > ticket originated with another CAS server (CAS2), the CAS1 server now > becomes a CAS client and asks CAS2 to do the validation (using the CAS > protocol), and then CAS1 just passes the response right back to the > client as if it (CAS1) had done the validation. > > That's it. This whole concept could probably be implemented in the > CentralAuthenticationService class. > > Of course, this concept scales to n CAS servers, but I do not know the > throughput of even doing this with just 2 CAS servers. But this > certainly makes CAS HA without a lot of extra baggage. The local ST > and PT ticket registry can be implemented in memcache or even a DB but > the nice thing about it is that they do not have to be replicated. As > I said in the beginning, the TGTs could be stored in something like > LDAP which does replication very well, but it is not fast enough for > STs and PTs. > > Please let me know what you think and/or if you need more clarification. > > Thanks. > > -lucas > > ----------------------- > Lucas Rockwell > CalNet Team > l...@berkeley.edu > > > > > _______________________________________________ > Yale CAS mailing list > cas@tp.its.yale.edu > http://tp.its.yale.edu/mailman/listinfo/cas > -- m...@forsetti.com Key ID:D6EEC5B5 _______________________________________________ Yale CAS mailing list cas@tp.its.yale.edu http://tp.its.yale.edu/mailman/listinfo/cas
