CASFilter authorizedProxy parameter

Question:
When would I need/want to configure CASFilter or CASValidateFilter's authorizedProxy parameter?

Answer:
Any service that authenticates users via CAS can obtain a proxy ticket
under the CAS protcol (you can, of course, locally restrict this with
fairly trivial local hacks).

This is okay because at validation any proxy ticket resolves to two
pieces of information: the userid of the end user, and the chain of
proxies. In the case of uPortal, this chain is the https: proxy ticket
callback URL of your uPortal server. If your uPortal proxied to a mail
servlet, which in turn proxied to an IMAP server, then the proxy ticket
the IMAP server validates will resolve to a chain including both uPortal
and the mail servlet.

CAS represents this chain in its proxy ticket validation response.
However, your application absolutely must examine this chain to see if
it includes services you actually want to accept proxying from. Your
IMAP server might accept proxying from uPortal but not from Sakai, say.
If you do not examine the proxying service's identity, then any service
could proxy through your filter.

The authorizedProxy init param is the way you configure CASFilter or
CASValidateFilter as to which services are authorized to proxy through
it. The filter by default accepts service tickets. It will also accept
proxy tickets whose most recent proxying service is listed among the
authorizedProxies.

In the case of configuring uPortal itself for CAS authentication, it
would almost never be necessary to configure this parameter (only end
users, not other services, would be authenticating to the portal itself).