On Mon, 2007-10-15 at 09:57 -0400, Marvin S. Addison wrote: > This is an interesting idea. I'm curious about your needs/use cases > that motivate this feature. Sounds like one of the driving forces is > reduction or elimination of server storage.
My use cases generally revolve around fault-tolerance without
replication. CryptoTickets in theory make the server stateless. This
would allow for simple clustering capabilities. No session replication
is needed. This is valuable in at least the following two scenarios:
*Remotely located CAS servers, such as with a CAS server per campus, for
fault tolerance, where replication over the WAN could be difficult
and/or dangerous.
*Clustering within a network which is not multicast capable, for
technical, political, or organizational reasons.
> I wonder, though, if you'd
> be trading ticket storage for key storage, unless you envision a single
> encryption/decryption key pair for all tickets. Would you mind
> discussing briefly key management?
I see two possibilities. Let's assume synchronous encryption, such AES.
The first possibility is that all CAS servers share a common key.
The term "magic" used below refers to some sort of
fault-tolerance/load-balancing mechanism which routes request to an
available node.
1) User access app1.example.com, and is redirected for login to
login.example.com, which is *magically* routed to either
cas1.example.com or cas2.example.com.
2) The user logs in to cas1.example.com. An ST is generated of the
form:
ST=Encrypt(key, timestamp + userid + service)
Where key is the shared key, and "timestamp + userid + service"
represents some delimited, concatenation of the authenticated userid,
requesting service, and the timestamp the ticket generation occurred.
3) The user is redirected back to app1.example.com, with the ST. The
stock CAS filter protecting app1.example.com parses out the ST, and
calls login.example.com/seviceValidate with the ST and service name.
This is *magically* routed to cas2.example.com .
4) cas2.example.com uses the shared key to decrypt the ticket:
timestamp + userid + service=Decrypt(key, ST)
5) After determining that the service matches as expected, and that the
timestamp is within the acceptable tolerance, serviceValidate returns
the standard XML response with the userid.
Note that the above flow is similar to Shibboleth's CryptoShibHandle
implementation.
Possibility number two would be to define a unique key for each service.
This would require key management, likely in the form of a fairly static
file that would be deployed to each CAS server. This would add the
benefit of allowing an extended CAS client to use its key to directly
validate its own ticket, without any callback. Note that this
implementation would be similar to Kerberos.
The above two possibilities could be implemented together - a default
global key always used unless there is a service-specific key defined.
>
> I think the violation of the single-use service ticket criterion is a
> serious one. One-time-use tokens are one of the strongest security
> features of CAS, not to mention it's a MUST in the spec.
Absolutely agreed. I'm not sure how the CryptoShibHandle deals with
this, but Kerberos generally employs an application-side replay cache.
> I wonder
> whether your proposed solution of used ticket storage would require
> _more_ storage than the current implementation of temporary storage of
> valid tickets.
Having a "used ticket registry" does require a lot of storage, but this
would be proportional to the ticket age tolerance. For example, if the
maximum allowed age for a ticket to be generated and validated is 15
seconds, then only tickets issued within the past 15 seconds need to be
remembered. Again, this would require state replication, which is what
I am looking to get away from. But, this replication could be made
optional, allowing those that need clustering but are willing to take
the risk to do so.
-Matt
--
Matt Smith
[EMAIL PROTECTED]
University Information Technology Services (UITS)
University of Connecticut
PGP Public Key: http://web.uconn.edu/dotmatt/matt.asc
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
