[cas-dev] CAS Java Clients

[Howard Gilbert]

> I suggest specifically researching the SAML "browser artifact profile."
> It is very similar to the CAS protocol.  I wrote up something a while
> back (probably a year or more ago) about the differences between CAS and
> the SAML browser artifact profile, and what it might take to make CAS
> support that protocol.

In the Artifact profile, the Identity Provider sends a short Artifact string
(essentially a Ticket) to the Service Provider. The Service Provider then
sends the Artifact back to a well known Web Service and gets back
(typically) a combination of authentication statements and attribute
statement about the user.

So yes, we have essentially the same elements, currently CAS has a vastly
simplified protocol thanks to the fact that the CAS server is both well
known (to the service) and trusted. Adding a standard exchange as an option
is reasonable, but the essence of CAS was to also provide the simpler
protocols that could be easily used by less sophisticated applications and
languages that lacked SAML libraries.

Since this opens the question, let me bring up the real difference between
CAS and the SAML world. This is not necessarily a feature of SAML itself,
but of a difference in the deep belief structure of SAML supporters. They
would argue that true SAML presents the original unvarnished unprocessed
authentication and attribute set. They would argue that it is unwise to
impose a middleman that "reprocesses" the SAML assertions made by the
institution that holds the original attributes.

CAS, on the other hand, tends to be a bit friendlier and maybe less precise.
This is particularly important when CAS is itself depending on a library to
authenticate the user (with a Smart Card, or using Active Directory
credentials, or using Tomcat X509 certificates). SAML has assertions that
can be very precise ("He authenticated using an X509 certificate presented
over an SSL/TLS socket"). However, if you turn authentication over to JAAS,
for example, you may not know which of several authentication methodologies
(K5, LDAP, ...) were tried under the covers and which succeeded. Things get
even muddier when you present a Proxy Ticket. Now do you tell the downstream
service about the original authentication, or do you invent a new
authentication SAML statement specific to Proxy CAS?

It is a personal opinion, but I believe that while there is room for both
philosophies, it may be a mistake to try and turn CAS into an "orthodox"
SAML application. If you want that, you probably want Shibboleth. That does
not prevent CAS from generating requests and responses in SAML format, and
maybe in SAML protocols. However, the value-add of CAS here may be that it
believes in being helpful and makes things simple for people who are trying
to build simple services. The help may be in filtering out all the detail
for people who don't want to know and aren't smart enough to parse the
detail.

This provides a long term philosophical distinction between CAS and
Shibboleth. If Harvard wants to describe someone as "PhD candidate in the
Statistics Department", CAS may be the component that translates this to
"Grad Student" to applications that only care about this, or to "non-Yale
student" to applications that only care about that. SAML has no box in its
diagrams for such a mapping function, and the true SAML believers think that
such simplification is an inherently bad idea, but I have found that this is
exactly what the faculty and departments really want from us.