[cas-dev] CAS Java Clients

[Howard Gilbert]

> * The CAS server could generate SAML assertions
>   - for clients that recognize SAML assertions/artifacts
>   - for federation with other SSO systems
>     (this could be done by integrating with Shibboleth,
>      Though raw SAML might be nice, too)

You can put the CAS filter in front of the current Shibboleth IDP and use
CAS (locally) to authenticate to Shibboleth for off-campus access (or access
to on campus resources that use a Shibboleth Service Provider API instead of
the CAS API). Strictly speaking CAS is not generating the SAML assertions,
but it looks a lot like it. You get a single sign on (locally). The
advantage of this approach is that the Shibboleth IDP is already configured
and documented to do the 100% pure SAML protocol and all the Trust and
Metadata configuration stuff that SAML requires.

At one point as a proof of concept I created a SAML version of the
serviceValidate response. In CAS3 terms, I created a view component that was
a Java class that generated SAML XML using the OpenSAML classes. When called
upon to generate a network response to the Ticket validation call, this code
created the nested SAML objects (Response containing a Statement containing
an Assertion) and populated it with the netid. I can root around and find
the code somewhere, but at the moment is mostly interesting as an example of
how to turn the response "gilbert" into about 8K of bytes. 


> 
> * The CAS server could accept SAML assertions
>   - for federation with other SSO systems
>     (this could be done by integrating with Shibboleth,
>      Though raw SAML might be nice, too)

If you have a Shibboleth Service Provider written in Java (I wrote one, but
the Shibboleth guys didn't like it for some reason) you can put the
Shibboleth filter in front of CAS, configure CAS to trust the filter and
take the RemoteUser as NETID, and then that is approximately done. This is a
little sloppier, however, because the remote principal name may require some
mapping or the local applications may require some recoding. Is "gilbert"
turned into "gilbert at yale.edu" when it gets to Rutgers? There are enough
Yale programs that believe that anyone authenticated to CAS is a local Yale
user that we don't want to start feeding non-local users to them unless they
indicate (by the URL they use to validate the ticket) that they are ready
for a new format response. 

> 
> It might be cool if CAS clients could consume SAML assertions, but I
> can't think of a good use case to drive that requirement.  I certainly
> can think of use cases for the others.

If CAS decides to vend attribute assertions to applications, then I expect
that we will agree to use some format derived from SAML for the purpose. It
makes a lot more sense than just making something up. However, I want to
suggest some reasons for not using "real SAML".

First, the big advantage to CAS is that you trust it. If it tells you that
this guy is "scott", well that's good enough. Ultimately, SAML tells you
that "George at ucla claims that this guy is scott at rutgers," and then it tends
to argue that each application or service has to make up its own mind about
whether to trust George at ucla and what the hell is some guy at ucla doing
telling us about someone at Rutgers. If you want to do institutional trust,
CAS suggests that you place all the burden in CAS and then let it deliver
simple unqualified statements that everyone else can believe. True SAML
believers are existential relativists who question whether anyone knows
Truth. CAS removes all the relativism.

That means that a CAS statement expressed in SAML format might be parsed by
someone with a basic XML parser and no particular SAML support. Real SAML
has to go through all the expiration date checks, signature checks, and
other stuff. With CAS you know all the checks will be good, so why make
them. You can extract the data with XPATH expressions.

The SAML guys keep looking for something that will be absolutely standard
across all institutions without any possibility of confusion. Attributes
that may once have had humanly readable names migrate, in the search for a
standard, to long numeric strings registered with some schema standards
body. CAS can turn this back to simple words.


> 
> Speaking of Shibboleth, it would be great if we had a
> plan/explanation/code/configuration for Shibboleth integration (I
> imagine Shib as a layer above the CAS sever) and possibly integration
> with some Liberty-alliance-compliant system.

Think about the suggestions above. Right now you can use CAS and Shib
together "out of the box" for simple things. As soon as things get to be
more complicated, you are fighting the problem itself and not the two bodies
of code. Although you can certainly embed Shib in CAS 3 (or maybe the other
way too), not everything that you can do turns out to be a good idea. The
real question is "Assuming I can combine them, how are they different from
each other?" I am tempted to say something Eastern about Yin and Yang. Vive
la difference.