Frederico, CAS is scalable. Cf. Jérôme's very recent presentation documenting 11 million authentications per day, 600 requests per second, served by a three node CAS installation using MemCache ticket registry, etc.
http://www.parleys.com/#play/5159944ae4b0ffdd7e058b69/chapter20/about CAS is extensible. That's the reason for the modularity, the many interfaces. One important way CAS can be extended is through its Spring Web Flow usage for the login flow. This presentation is dated, but the concept remains applicable: https://vimeo.com/11631079 CAS has adoption for high availability use cases today. See for example this presentation on high availability CAS at Lamar University in the face of hurricanes: https://wiki.jasig.org/x/zhIoAw CAS server implementations are available for a variety of platforms, including Ruby, PHP, and of course Java. CAS client libraries are available for Java, .NET, PHP, and other platforms. CAS uses JSP and CSS and the look and feel is customized in the normal way using commodity web development practices. CAS speaks the CAS protocol for communication between the CAS server as IdP and CASified services as relying parties. CAS can also be made to speak a modified CAS protocol conveying attributes and has growing support for other protocols i.e. OAuth. Cf. https://wiki.jasig.org/display/CASUM/Protocols CAS has a pluggable AuthenticationHandler interface with implementations for supporting a variety of means of authenticating credentials. Primarily username and password credentials, but also e.g. x509 certificates. Cf. https://wiki.jasig.org/display/CASUM/Authentication As I understand it, the OAuth support in CAS 3.5 can be leveraged to accomplish login to CAS using Facebook. I feel more secure in that understanding for Jerome's comment on this presentation: http://www.slideshare.net/microcline/whats-new-in-cas-35 CAS offers a "remember me" feature. Cf. https://wiki.jasig.org/display/CASUM/Remember+Me CAS offers an audit trail, gathers some statistics, is inspectable using JMX, and Unicon has recently contributed a new take on eventing in cas-addons that might help on this front as well. CAS works for relying parties across domains and sub-domains. CAS has documentation, primarily in the Jasig wiki. Embedding login forms in services is in my humble opinion a worst practice and avoids some of the advantages of centralized single sign-on, but people have done this from time to time. CAS has an active community. Lists. Conference presentations. More general blogs and integrations out in the world. CAS supports Google integration both with Google accounts as a means to log in to a CAS server and with a CAS server as a means to log in to a Google for Domain account. You can delegate to JAAS for credential validation if you really want to, and likewise a CAS client library can expose JAAS abstractions if you really want it to. cf. https://wiki.jasig.org/display/CASUM/JAAS and https://wiki.jasig.org/display/CASC/JAAS+Integration . > Andrew Petro says that he sees CAS as "a flexible and capable mechanism for the Web authentication of local users." and Shibboleth as "the platform for federating that local Web authentication and implementing formal standards", ... . But I cannot connect this statements to the techical facts. Sorry to hear this continues to be confusing. I thought this recorded conference presentation was quite good, it may help: https://wiki.jasig.org/x/AxMoAw > Can I say that a "federated" scenario is SSO applied to sites in different domains (or sub-domains)? > Can I say that a "federated" scenario characterizes that the identity provider should gather user informations in different organizations (protected databases or directories)? > Doesn't the CAS server support authentication across multiple domains or sub-domains? Yes, CAS supports CASified services across any domains and sub-domains you like; no, that's not what's meant by "federation". Federation ensues when you have multiple providers of identity and of services from different organizations. So, perhaps, some of your customers operate their own Identity Providers and they might use those to log in to services that your company provides. Or, likewise, your company might provide an Identity Provider whereby your employees could log in to applications (Service Providers) operated by your clients. Cf. InCommon. In principle, users and identities from any of these 290 identity providers: https://incommon.org/federation/info/all-entities.html#IdPs could log in to any of these 1071 service providers: https://incommon.org/federation/info/all-entities.html#SPs (The technology allows this; a policy layer governs who accepts what identities from what; discovery services attempt to make the experience of all this sane.) CAS is a great solution for implementing single sign-on involving a single identity provider and a set of service providers intending to allow login primarily or only through that single identity provider. I.e., the typical within-institution single sign-on use cases. CAS doesn't particularly support the federated use cases -- that's where Shibboleth comes in, and shines. > What Andrew meant by "implementing formal standards", doesn't CAS support SAML too? Not to anything like the extent and formality that Shibboleth does, no. CAS 1) has just enough SAML support to accomplish login to a few services, such as Google Apps for Domain, and 2) happens to use SAML as the XML representation for user attributes on a particular validation endpoint. This is fine as far as it goes, but it doesn't extend to supporting profiles for exchange of assertions that would make SAML implemented formally and interoperable. Which is just fine, since CAS and Shibboleth can be used beautifully together. Kind regards, Andrew On Tue, Apr 2, 2013 at 7:37 PM, Frederico Guilherme Zveiter de Albuquerque < [email protected]> wrote: > Hi, folks! > > First of all, let me apologize for my bad english. > > I'm responsible for present a solution for implementing SSO in three sites > that composes the products on my company. During a meeting last week I've > presented Jasig CAS Server and CAS protocol as a possible solution and made > a little demo and they all liked but there were many questions that I could > not answer because my lack of knowledge in SSO and the short time I had to > do the presentation. > > I'm in need of help in order to create a comparison sheet that states > about CAS, Shibboleth, JOSSO and Picketlink on the following topics. > The statements should not be too deep, just suficient to support an > overview analisys between the solutions. > If anyone could contribute in any of the topics of any os the solutions > I'll be very grateful! > > Must have features: > > - Scalability > - Extensibility > - Adoption and use cases in production today (preferably in high > availability scenarios) > - Interoperability between Java, .NET, PHP and others. > - Look and feel customization of server's user interface. > - Communication protocols between identity provider and services. > - Communication protocols between identity provider and authentication > providers. > - Facebook as authentication provider. > - "Remember me" feature. > - Auditing and statistics. > - Suport for multiple domains and sub-domains services. > - Documentation. > > "Nice to have" features: > > - Use of login forms in services. > - Active community. > - Google integration (OpenID/SAML) > - JAAS integration. > > As a related subject, I'm (very) confused about the roles and features of > CAS and Shibboleth. In his blog post entitled "CAS and Shibboleth > Co-existing in Mutually Beneficial Harmony", Andrew Petro says that he sees > CAS as "a flexible and capable mechanism for the Web authentication of > local users." and Shibboleth as "the platform for federating that local Web > authentication and implementing formal standards", also, in Shibboleth's > about page, it is stated that this "federation stuff" is the title given to > the scenario where the identity provider and identity services are not > necessarily in the same organization. But I cannot connect this statements > to the techical facts. > > Can I say that a "federated" scenario is SSO applied to sites in different > domains (or sub-domains)? > Can I say that a "federated" scenario characterizes that the identity > provider should gather user informations in different organizations > (protected databases or directories)? > Doesn't the CAS server support authentication across multiple domains or > sub-domains? > What Andrew meant by "implementing formal standards", doesn't CAS support > SAML too? > > Please, help! > > Thank you very much! > > *Frederico Zveiter* > > -- > 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
