Sneak Password Back to Trusted Applications

It's not pretty, but some applications other than CAS can need access to the end user's password, such as portals and webmail applications. CAS's highly compelling proxy authentication technologies should be preferred. However, schools with no less a stature than Rutgers University herself have in practice need a need to pass the password out of CAS. There should be an off-by-default, standardized, well-documented, secure, soberly-considered implementation of this feature. This may be something achievable as an add-on to CAS 3.x rather than or in addition to for CAS 4.

Discussion of this issue

This issue/feature/direction has been discussed on the CAS email lists. (TODO: link some relevant discussion).

The uPortal angle

uPortal 3.0 ships with CAS 3 included-with as the go-to default way to implement authentication.

This is really cool.

Historically, while CAS approaches are preferred, many schools have needed to use password replay technologies to access some backing systems (e.g., non-CASified IMAP for email previews) and to broker poor-man's single sign on with other web applications through JavaScript-driven form posting. While these approaches are less attractive than CAS proxy ticket approaches, it would be best if they remain feasible in uPortal 3 without the basic story being one of giving up on the included CAS.

Implementation possibilities

The end user credentials could be conveyed to particular applications piggybacked on the PGT conveyance. This is nice in its re-using of existing approaches for authenticating the applications to which CAS is granting PGTs.

The end user credentials could be treated as user attributes and released via the user attribute release mechanisms in CAS 3.2.

An entirely new callback could be invented for conveyance of the password.