_____
Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Jason Shao Skickat: den 27 juni 2007 11:02 Till: Yale CAS mailing list Ämne: Re: Making a case for CAS in reference to Shibboleth On Jun 26, 2007, at 4:36 PM, Andrew R Feller wrote: Couple of questions I would appreciate community feedback on: 1. Why use CAS with Shibboleth if Shibboleth can act as a SSO? Well, as with choosing any product/project -- I think the answer has to be that there's some feature within CAS that you find attractive. While I don't know a lot about your architecture, from an *implementation* focused perspective some of the attractive features of CAS, specifically CAS 3/3.1 are: * many already implemented connections to backing user stores: e.g. LDAP, DB, Kerberos, Radius etc. * a large library of pre-written clients for Apache, .Net, Java, PHP, PAM, Perl, Ruby, and many other languages/platforms * OpenID Provider Support * support for many credential types including: username/password, X.509, SPNEGO, and others * well defined extension points for service-management, sophisticated authentication workflow, etc. * A growing number of applications/services with OOTB or available open-source integrations with CAS, especially in HE focused products/projects. [Pål Axelsson] Two more things: * CAS is easy to integrate in applications with out using web server filters due to the fact that simple http redirects and http calls can be made in side the application * CAS has a capability for web applications to act as an proxy authenticator for applications behind a web frontend 2. If CAS and Shibboleth are used together, which should be configured to protect resources? Shibboleth SP or CAS client? I suspect it's going to depend on the resource you're providing authentication for. Questions I would consider: * Does it make sense to expose your resource in a federated context? * Do existing integrations exist for either Shibboleth or CAS? [Pål Axelsson] Shibboleth doesn't need to be used in a federated context and the capability in Shibboleth to transfer attributes with the login session is very useful if you don't want every application that needs attributes to read your LDAP-catalog. In our case Shibboleth is piggy backed to CAS so that Shibboleth uses CAS for login and we plan to use both to protect resources. Which client is used for which application depends on the application. Should it be federated? Is there built in support for CAS or Shibboleth? Does the application need attributes from our catalog? is some of the questions that needs to be answered in choise of login client. The first question was the most asked question I received while attending the Shibboleth conference in Portland, OR this week. I am at a loss aside from an initial comment of how some products (uPortal) we are interested in deploying have CAS authentication modules. The second revolves around the response of using both together. In summary, depending on your scenario I think the answer is: 1. there may be CAS capabilities (protocol & ecosystem) you wish to take advantage in some contexts, or in addition to federated auth. 2. details of the CAS implementation may fit in better with your existing enterprise system, and lessen the work required to integrate Pål Axelsson IT Support Department Uppsala universitet Sweden
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
