SIngle sign-on protocol is a way to authenticate the users one only time avoiding to reinsert continually username and password for accessing to other services. The process is comfortable from user point of view, secure and scalable for who will manage it.
The father of all authentication protocols is the kerberos, standard de facto in every Identity Management system used inside a company. The most widespread identity system like Active Directory and Freeipa are kerberos based.
With the spread of web and cloud, it was necessary to think of new systems that exceeded certain kerberos limits. For that scope, new protocols were born like CAS.
In this article I will try to explain the differences and similarities between kerberos and CAS. For doing that, I will explain the main features of kerberos and CAS comparing between them.
Let’s start with kerberos protocol
Kerberos is the protocol most used in modern authentication systems. Active Directory and other Identity management (like freeipa) use it for offer a single sign-on authentication method.
I will explain only the main features of kerberos protocol, for the detail you can read this my article https://www.securityandit.com/network/kerberos-protocol-understanding/.
The kerberos protocol is based on getting after trying your identity a Ticket Granting Ticket (TGT). The TGT is encrypted with a secret kerberos ticket and it contains a session key shared between client and server. The meaning of TG_REQ is that: I would like to receive a service ticket (ST) for accessing to some service; for proving that I’m a regular user authenticated I ciphered a part of request with my session key; the session key is valid because present in TGT that only KDC can decrypts.
The scope of the protocol is to get a service ticket to show to service where you need to be authenticated. The TGT is used for proving your identity without the need to reinsert again username and password that never sent in the network by a single sign-on authentication approach.
The TGT and the ST are sent on top of UDP or TCP packet. The kerberos protocol used is 88. The security is inside the protocol and not delegated to other protocols.
The protocol provides security, scalability and user management benefits and it’s the standard de facto used in Active Directory and freeipa.
Its limit is due the fact that every system or service must be joined to domain. This approach can be followed in a Intranet but in Internet where the users that consume the web services are not manageable cannot be implemented. It’s necessary a new protocol with the same features without the need to provision the systems to domain.
CAS protocol exceeds the limit of kerberos implementing a simple single sign-on protocol over HTTP without the need to join to domain the system where the services are used.
Le’t go to explain the main features of CAS comparing with kerberos protocol.
The CAS protocol is a simple single sign-on protocol for the web and permits a user to access to different web service providing one only time username and password.
I will explain only the main features of CAS, for the details you can get more that I know in the official implementation of the protocol: https://apereo.github.io/cas/4.2.x/protocol/CAS-Protocol-Specification.html.
For better understarding what I say, you can follow the diagram sequence provided by apereo: https://apereo.github.io/cas/4.2.x/protocol/CAS-Protocol.html.
As kerberos, CAS protocol has as key concepts the Ticket Granting Ticket (TGT), stored in the CASTGC cookie released from CAS server to client (browser) after authenticated it by username and password and the Service Ticket (ST) that will be used for authenticating to different web servers by a SSO approach.
The TGT has the same meaning of kerberos protocol: it means that the user has been successfully authenticate. It can be showed to CAS for obtaining a new service tickets for a different web services as the TGT kerberos is showed to KDC server for getting a new ticket for a different service.
The only thing to do is to register the service in the CAS server as every service is joined in the KDC domain, and putting the certificate authority in the key store of the service.
The client (browser) must not preconfigure anything: it will be redirected by a HTTP 302 from service to CAS service for getting the service tickets. If the browser doesn’t have any CAS cookie, a GUI login page is showed and after successfully authenticating the user, a new HTTP 302 redirect to service is returned where the service ticket will be presented as parameter (please see the sequence diagram in the link above).
The web service will call the CAS service for validating the service key and of course authenticating the user. Instead in KDC protocol, no interaction happens between service and KDC server because the authentication process is implemented by a secret key shared between them during the service registration in the domain.
Every service during the service ticket validation can asks to CAS Server a Proxy Granted ticket to use for getting new service tickets for authenticating to call back end services. This ticket is called PGT and it’s sent by CAS to service in a ppgURL specified during the service ticket validation.This feature is not present in the kerberos protocol.
The protocol security is delegated to SSL. Infact all the communications with CAS server are in https in order to avoid main in the middle attack, as opposed to Kerberos that is itself secure.
Another feature of CAS protocol is to delegate the authentication to third party system: another CAS server, an OAuth provider like Facebook, Twitter, Google, LinkedIn, Yahoo and several other providers. Kerberos has instead the concept of domain trust that permits to user from other domain to have the right privileges to internal resources.
We can summarize the comparison in the following table:
|Ticket Granting Ticket||Yes||Yes|
|Secure||Yes||No (Yes with SSL)|
|Proxy Granting Ticket||No||Yes|
|Delegation with external party||No||Yes|
|Trust with with external party||Yes||No|
|Web Resource Authentication||Yes||Yes|
|Other Resource Authentication||Yes||No|
|Scalable on Internet||No||Yes|
I summarized the main features and the differences between CAS and kerberos protocol. In a private environment like a LAN, kerberos is the ideal solution not just because every system can be joined to domain but also because the protocol permits the authentication and authorization to different type of resources: web resources, printers, ssh and rdp logins, network shares, etc.
CAS is the good solution for managing the authentication to web resources where the clients are distributed in internet. It is a solution for accessing web resources and in a intranet can be used together with Kerberos for having a scalable, resilient and secure single sign-on authentication.
Don’t hesitate for any questions or doubts.