Hi Adam,
Thanks for the feedback. I have some comments in-line.
On Jan 19, 2009, at 2:18 PM, Adam Rybicki wrote:
Lucas,
I believe that Andrew Feller and I have once, briefly, discussed a
similar approach. This was off list. I think that my comments that
follow are my own and not Andrew's especially if I am wrong. ;-)
Anyhow, this is doable, but it may introduce additional complications.
This approach technically, in a small way, changes the CAS protocol
by deriving the originating CAS hostname from the ST or PT. No harm
done, as long as you prevent the scenario that Matt described with
someone sending a ticket with a bogus CAS hostname.
I think that Andrew and I talked about a slight variation of your
approach where the CAS server unable to validate an ST would use its
own list of other CAS servers to try to get the ticket validated.
While preventing the scenario that Matt warned about, this has its
own set of issues:
If there are many CAS servers, you might have to try several servers
before you succeed in finding the CAS server that can validate the
ticket.
In my approach, there would only be one place where the ticket could
be validated -- the host that originated the ticket. So, there is no
need to try multiple locations. The ticket is inspected for the host,
it is cross-checked against a local list of known hosts, and then it
is validated against that host (which may be the localhost, in which
case the server acts like it normally would).
There would need to be some clever way to prevent trying forever.
Assuming only 2 CAS hosts for simplicity, I think that just simply
following this scenario with an invalid ST could result in:
CAS1 unable to validate the ST, so it asks CAS2.
CAS2 unable to validate the ST, so it asks CAS1.
This is not an issue, as described above.
A distributed ticket registry does not care about which ticket types
should be replicated. So, to select the tickets for replication,
another CAS modification would be needed. Nothing that more
programming wouldn't address, but it's still something new to worry
about.
A registry cleaner that cleans the replicated tickets differently
than the "local" tickets might need to be written.
Ok, I was under the impression that they could be easily separated. In
that case, then all tickets could still go to the cache (which could
still be LDAP). If using LDAP (an LDAP dedicated to CAS), then it is
possible that the CAS server could try the cache first, and if it is
not there (yet), then it could look at the ticket to determine where
it came from and then ask that server to validate it. I think this is
a more complicated scenario, however.
I mention LDAP a lot as that is my current line of thinking of doing
ticket replication -- again, only appropriate for TGTs as (Sun,
Fedora, and OpenLDAP) LDAP replication is asynchronous and not fast
enough for STs and PTs. (Given Adam's comments, I think I will just
replicate all tickets in LDAP regardless.)
So, the idea is that each server would have CAS and an LDAP server,
with each LDAP server configured for replication to the others. Of
course, if one of the LDAP servers goes off-line one of two things
could happen: 1) The local CAS server could try another LDAP server as
a backup until the local LDAP server comes back on-line, or 2) Refuse
connections until the LDAP server comes back online. 1 would probably
be a better option.
I think the first thing to try, however, is to just enable LDAP as a
ticket store and see how it holds up to load-testing on just one host
using an unmodified CAS server.
-lucas
Lucas Rockwell 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
<arybicki.vcf>_______________________________________________
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
