ProxyTicketReceptor

How does ProxyTicketReceptor work? Does it leak memory?

A: It's probably worth describing this in a bit of detail. In terms strictly of CAS's protocols, the PGT IOU is used exactly once by a "proxy" to retrieve a "proxy granting ticket" (PGT). As far as the CAS server is concerned, the IOU has only this function (which in turn serves to authenticate the proxy).

In the ProxyTicketReceptor code — one mechanism provided by the client library to make it easier to set up a CAS proxy — the IOU is used also as a convenient handle that lets code calling

ProxyTicketReceptor.getProxyTicket()
retrieve a proxy ticket. In other words, you need some way to identify the PGT that you want to use when you call getProxyTicket(), and using the PGT itself might be less secure in a portal environment in which you don't trust individual channels (i.e., callers of getProxyTicket()) with sensitive information (such as a plaintext PGT). The ProxyTicketReceptor could easily generate an arbitrary handle and make sure clients get this handle, but the IOU happened to serve this function conveniently, so there was no reason to bother with a separate handle.

Thus, while the IOU is "used" only once as far as CAS is concerned, it continues to be used by ProxyTicketReceptor and the code that calls it. So an arbitrary fixed timeout wouldn't be appropriate; the PGT might outlast this timeout. However, since the PGT expires after a period of disuse, an inactivity timeout in ProxyTicketReceptor might be appropriate, as might the weak reference you suggest. (I haven't thought the latter through — perhaps uPortal persists data in ways that would cause a weak reference not to work as you expect — but it makes sense on the surface, for you only want to keep the data in the ProxyTicketReceptor's Map as long as someone else has a reference to it. But, for instance, in a distributed environment involving multiple JVMs, an inactivity timeout might be easier.)

Another alternative would be to add a clean-up method to ProxyTicketReceptor called by code that invalidates a user's session or otherwise logs a user out.

Note that the data in the Map is so small, in practical terms, that it's unlikely ever to grow to a point that's problematic.

Originally answered by: Shawn Bayern on the CAS mailing list.