What are the differences between CAS protocol and SAML protocol?

Question

If both protocol are both used to provide SSO, what are the reason to use one over another? Can you please list out some major difference between them which make them suitable for different tasks and situations?

Note: I'm not talking about the CAS software, I'm talking about the CAS protocol.

Answer 1

SAML (Security Assertion Markup Language) as well as CAS (Central Authentication Service) are Single Sign On (SSO) protocols (or standards) used to manage access control decision.

---

SAML stands for Security Assertion Markup Language (pronounced SAM-el) and it is an open standard for exchanging authentication and authorization data between parties, in particular, between an IdP (Identity Provider), ie. SaaS company that stores usernames and passwords, and a SP (Service Provider) ie. your website or service.

SAML is an XML-based markup language standard for security assertions. It contains: a set of XML-based protocol messages, a set of protocol message bindings and a set of profiles (utilizing all of the above).

In simple words, SAML is an XML framework (standard) for SSO (Single Sign On) which can be used by various applications to authenticate ("you are, who you are saying you are") or authorize access ("you have access to this application part").

---

CAS, on the other hand, stands for Central Authentication Service and is similarly a single sign-on, ticket-based protocol standard or framework. Its purpose is to permit a user to access multiple applications while providing their credentials (such as user id and password) only once.

The name CAS also refers to a software package (called Apereo CAS) that implements this protocol (it's worth to note that even if the primary goal of the CAS server is to implement the CAS protocol, other protocols are also supported as extensions, ie. Apereo CAS Server also contains ability to implement SAML).

The key concepts with CAS are: The TGT (Ticket Granting Ticket), stored in the TGC cookie, represents a SSO session for a user, and the ST (Service Ticket) - transmitted as a GET parameter in urls - stands for the access granted by the CAS server to the CASified application for a specific user.

One of the most powerful feature of the CAS protocol is the ability for a CAS service to act as a proxy for another CAS service, transmitting the user identity.

---

Special considerations when choosing SAML or CAS:

SAML:

• Registration between SP and IDP is mandatory, can be done with public metadata exchange (you need to agree beforehand what metatags will be sent between SP and IDP)

• XML messages can be signed and/or encrypted with the help of asymmetric keys (public keys published in metadata)

CAS:

• No obligation to declare CAS clients in CAS server (open mode)

• Trust between CAS client and CAS server relies on CAS server certificate validation

---

Conclusion: (as per this presentation):

SAML: complex protocol, very often used for SaaS authentication, good security, well established

CAS: simple protocol, no strong security, fits internal usage

Answer 2

This is a proprietary protocol developed exclusively for the CAS server.

However:

"Even if the primary goal of the CAS server is to implement the CAS protocol, other protocols are also supported as extensions:

OpenID
OAuth
SAML"

Because the CAS protocol is proprietary, it is not supported by IDP's e.g. Azure AD, ADFS, Auth0 etc.

So if all you want to do is use the CAS protocol to talk to the CAS server, that will work.

If however, you want to talk to another IDP, you cannot use the CAS protocol to do this. You would have to use one of the protocol extensions as above.

It is also possible to write a bridging protocol. This way you can continue to use the CAS protocol but the IDP sees it as OpenID Connect

So if in the CAS world, use the CAS protocol but if you need to use other IDP, stick to the standard three protocols.