...
| Warning | ||
|---|---|---|
| ||
All of these caches have to be replicated in a clustered installation. For example, if CAS is to be clustered, its Ticket Registry and the optional ClearPass cache need to be replicated. Obviously, sending these across the network needs to be done carefully. |
The default implementation of ClearPass cache is a username/password map--an ideal place for hackers. Storing a map like this in memory would get some security experts worried. Sending the updates to this map across the network in clear text is just plain reckless.
A recent CAS Community call presentation by Howard Gilbert discussed securing Ticket Registry by hash-encoding the TGT identifiers prior to storing them in the registry. This idea is probably only OK for Ticket Registry because in the other instances (list above) the items must be recovered in their original form. So, for those items would have to be symmetrically encrypted.
Some implementers of CAS, being aware of security risks, have chosen to use site-to-site VPN or other methods of securing the cache replication channel.
Some implementers of CAS have chosen to release password as a CAS attribute, a significantly less secure method than how ClearPass does this. If CAS protocol were to be ever upgraded to permit attribute release, perhaps mutually-authenticated SSL transport would be required to secure the release of sensitive attributes. That would be similar in a way to how SAML does this with signed/encrypted assertions, but instead using the SSL stack to do the x509 certificate stuff.
In a follow-up to this session on the cas-dev list, couple of contributions were made available for one-way and symmetric encryption. The contributions were just starting points that would have to be refined.