[cas-dev] CAS Java Clients

[Velpi]

>> * 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.

We're using that setup with great succes. I finished our installation guide for 
that today, so if anybody wants to set up a similar thing feel free to use the 
pointers at http://shib.kuleuven.be/docs/idp/install-idp-1.3.shtml

At the moment we see it being used like this:
* all initial authentication: CAS (because of security, flexibility and proxy)
* authN for Shib: CAS protocol to SSO servlet (Java CAS client)
* intra-campus proxy stuff (eg webmail) => CAS protocol
* native java things: Apache frontend&SAML or CAS
* other stuff: SAML/Shib (inter-institutional (ready))
[we're now deploying this setup successfully with CAS3 at 13 partner institutes]

Both systems have their advantages and I think it is a good idea not to put any 
effort in integrating them, but rather to let them work together smoothly (which 
they already do, actually). It greatly enhances the flexibility of your entire 
AAI system (as we call it).
Like Howard says: they're complementary.
My opinion: let's keep it that way and make sure both things are/stay the best 
you can get in their area (as they are now).


--Velpi