To CAS or not to CAS

1
To CAS or not to CAS

• Is CAS the hidden gem of authentication APIs or
  should it be end-of-life? Unequivocally, Gluus
  position is the latterCAS 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.

2
If you compare CAS and OpenID Connect, youll 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 flexibleusing 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,
dont forget Siteminder in the Enterprise world
however, if youre faced with the situation try
NOT TO CAS.   Article Resource -
http//thegluuserver.wordpress.com/2013/11/14/to-c
as-or- -cas not-to