> Typically this means the deployer > configures the native SSO features of Tomcat (or whatever container the > Shib IdP is running in) to provide the user interface and credential > verification functions.
We chose to use CAS as the SSO system on top of the Shibboleth SSO system. So CAS does our authentication (not Tomcat, although we considered that). This has proven to be a good choice as CAS is far more powerful and flexible. This also gives you to option to use the CAS protocol where Shibboleth can't help you out [eg proxyCAS]. (eg see http://shib.kuleuven.be/docs/idp/install-idp-1.3.shtml) I know I'm not asked, but my idea of THE best future is some kind of ShibboCAS application that has the power of CAS for AuthN and proxying (currently typically intra-institutional) and the power of Shibboleth (SAML) for inter-institutional SSO and attribute release. Integrating both somehow to one solid block would result in the same combined strength as CAS+Shibboleth, but it should be a lot easier to manage... -- Velpi _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
