Hi, While there are "Disadvantages to using both CAS + Shibboleth", I think that there is merit in a "CASified" Shib IdP. It lets web apps deal with authN (identify the user) simply and handle their own authZ (control access). A "CASified" Shib IdP doesn't do authN but defers to CAS. Web apps (a.k.a., service providers) get data about an authenticated user from the Shib IdP so that they can make appropriate access control decisions. But CAS can also be configured to provide similar data so I think that the trade-offs between CAS and Shib deal with how easy it is to parse the response to get at the data.
Being the implementer of CAS at the University of Hawaii and now working on getting a Shib IdP up and running, I'd like to make it easy for the web app developers (carrot not stick). I'm considering the "CASified" Shib IdP approach for this reason. Retaining use of our existing CAS (a customized version 2) with a Shib IdP would make the move to Shib smooth and less disruptive. We can force the use of Shib for authZ by making authZ data available only through Shib and configuring CAS for only authN as it was originally envisioned. Hope this helps, Russ On Tue, 17 Feb 2009, Isaac Davis-King wrote: > This is an interesting poll from the perspective of our institution. We are > in the process of implementing SSO for the first time. Currently 99% of our > services authenticate against Active Directory using the same user id and > password, so the move > to a SSO solution is not a radical shift. Originally we began experimenting > with CAS, but then the CSU system began an initiative for implementing > federated login using Shibboleth. At that time we figured it made sense to > stick with one SSO product, > and we were being required to implement Shibboleth anyway. > > But in the process of experimenting with both Shib and CAS and integrating > various applications, we have begun to realize that CAS is a much more mature > pure SSO product than Shib. We have now decided to implement both side by > side and use CAS as > the authentication mechanism for Shib. We will use CAS as the primary SSO > product, and then use Shib when it makes sense. I would be interested to hear > the perspective of institutions that use both and prefer Shib. > > Here is the breakdown of the pros and cons to each approach as we see them: > > Shibboleth Advantages > • Federation + Single Sign On in one product > > CAS Advantages > • Much more mature pure SSO functionality than Shibboleth > ◦ Proxy authentication support for portal applications *big > deal* > ◦ Single Sign Out - Although still safer to train users to exit > browser > ◦ Built in support for customization of logout page based on > service > • Much simpler to 'CASify' a web application than to 'Shibbolize' > (less administrative overhead) > ◦ CAS uses simple API with libraries for many languages > ◦ Shibboleth SP requires daemon installed on each server, xml > configuration, as well as API > • Wider built-in support from 3rd party web applications > • Other institutions in the CSU (Cal Poly) have already successfully > CASified Peoplesoft *big deal* > > Disadvantages to using both CAS + Shibboleth > • Increased server load > ◦ Two Tomcat applications instead of one > ◦ Double the requests for each Shibboleth SSO instance > • Added complexity (one more session to keep track of) for Shibbolized > Apps > • Need to maintain two SSO server applications > • Need to maintain expertise in both CAS and Shibboleth > > Advantages to CAS + Shibboleth > • We can take advantage of SSO strengths of CAS > • We can take advantage of federated log in with Shibboleth where needed > • Less administrative overhead for CASified applications > > > > -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
