To CAS or not to CAS

1. Is CAS the hidden gem of authentication API’s or should it be end-of-life? Unequivocally, Gluu’s position is the latter–CAS filled a needed gap at the time, but now application developers should be discouraged from expanding the use of CAS. Here is why… Background Developed at Yale in the early 2000's, CAS is now hosted by Jasig, a consortium that fosters open source software projects for higher education. CAS version 2.0 was finalized in 2005 about two years before the iPhone was introduced. CAS is known for its developer friendly (easy) client API. There are lots of CAS libraries for different programming languages, and many plugins are available for other open source projects. Its also supported by some vendors. For even more background, Wikipedia gives an informative overview of CAS. Why not use CAS? There are a few reasons you should steer clear. CAS does not support OAuth2, and it probably never will. Faceook, Google, and Yahoo use OAuth2 for authentication, which represents about 85% of consumer authentications according to Janrain (provider of a widely used uber-authentication-api). Large consumer IDPs that are using OAuth2 are likely to quickly adopt the “OpenID Connect” profile of OAuth2, which will incentivize a staggering number of websites to follow. This will overshadow all previous web SSO/federation standards like CAS, old versions of OpenID, old versions of OAuth, and even SAML. To CAS or not to CAS

2. If you compare CAS and OpenID Connect, you’ll see not only does CAS have less features for authentication, but it does not support many of the endpoints defined by Connect: dynamic client registration, discovery, user claims, client claims. So its not just a matter of a different protocol for authentication, but a lot of missing functionality. Even SAML support is weak. Many institutions that want both CAS and idp SAML use a “Login Handler” in the Shibboleth SAML IDP software to validate the username/password creds against the CAS server. In this way, the person gets both a CAS token and a SAML token, and has SSO with both kinds of apps. In CAS, its not that easy to implement new types of multi-step authentication. Most deployments of CAS are for username/password authentication. While its easy for mobile applications to use the CAS API to validate credentials, the protocol does not lend itself to more complex authorization scenarios where the backend services have different levels of permissions. Conclusion Like the little ant, OpenID Connect has high hopes. Where possible, use it. Make sure developers understand the roadmap for your organization: your domain, like all the other domains on the Internet, will adopt OpenID Connect. Use SAML to fill in the gaps until all the OpenID Connect libraries and web server plugins are available. SAML is going to be around much longer than CAS, so its a better bridge solution. Use CAS only as a last resort. You should require products and software that supports the identity integration method that align with your roadmap. Be flexible…using CAS is better than the app storing its own passwords. However, realize that this application will probably never support the two factor authentication services available in OAuth2 and SAML. There are many “good” legacy SSO protocols, don’t forget Siteminder in the Enterprise world… however, if you’re faced with the situation… try NOT TO CAS. Article Resource :- http://thegluuserver.wordpress.com/2013/11/14/to-cas-or- -cas not-to