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.
    • 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.
  • 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.
Adam

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

  
begin:vcard
fn:Adam Rybicki
n:Rybicki;Adam
org:Unicon, Inc.;Professional Services
adr:Suite 113;;3140 North Arizona Avenue;Chandler;AZ;85225;United States
email;internet:[email protected]
tel;work:+1-480-558-2400
tel;home:+1-310-265-8286
tel;cell:+1-310-980-2758
x-mozilla-html:FALSE
url:http://www.unicon.net/
version:2.1
end:vcard

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas

Reply via email to