We thought about doing something similar at Columbia a few years ago,
but ultimately went with a DB backed store. Our concerns included
(1) Only 1/n (where n=# of servers) validation requests would hit
the correct server and not need forwarding, meaning an increase
of (n-1)/n transactions
(2) It wasn't replication, so if a server went down, we would
still lose 1/n of the login state, meaning we couldn't
really call this high availability
-Benn-
Lucas Rockwell <l...@berkeley.edu> wrote on January 15, 2009 1:57:12 PM
-0800:
] 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
_______________________________________________
Yale CAS mailing list
cas@tp.its.yale.edu
http://tp.its.yale.edu/mailman/listinfo/cas
