[cas-dev] CAS Java Clients

[Nathan Kopp]

To clarify... by "Shibboleth integration" in my previous e-mail, I was simply suggesting that we do something just like you've done -- a detailed description of how to use CAS and Shibboleth together.  I think it would be worthwhile to create an "official" how-to document the main CAS website.
 
It would also be interesting to see a detailed explanation of using a Shibboleth SP as an authentication front-end for CAS, so that CAS could accept SAML federation assertions from other institutions.  Didn't someone recently mention doing just this sort of thing?  It would be really interesting to see a nice concise explanation of the setup necessary to make both of these scenarios available on the same system (where CAS uses Shib to both accept and generate SAML assertions for federation), if that is possible.
 
If the "integration story" with Shib is solid, then this decreases the motivation for CAS to support SAML directly.
 
-Nathan
 

________________________________

From: cas-dev-bounces at tp.its.yale.edu on behalf of Velpi
Sent: Tue 5/2/2006 7:01 PM
To: Mailing list for CAS developers
Subject: Re: [cas-dev] CAS Java Clients



>> * 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
_______________________________________________
cas-dev mailing list
cas-dev at tp.its.yale.edu
http://tp.its.yale.edu/mailman/listinfo/cas-dev