Hi Matt, On Jan 15, 2009, at 2:58 PM, Matt Smith wrote:
> 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. Absolutely. That was the part about, "Make each CAS server aware of its peers." This would probably be done in an XML config file. -lucas > On Thu, Jan 15, 2009 at 4:57 PM, Lucas Rockwell <[email protected]> > 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 >> [email protected] >> >> >> >> >> _______________________________________________ >> Yale CAS mailing list >> [email protected] >> http://tp.its.yale.edu/mailman/listinfo/cas >> > > > > -- > [email protected] > Key ID:D6EEC5B5 > _______________________________________________ > 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
