Re: [cas-user] Why the need for service ticket in CAS?

[Ray Bon]

Yan,

There are two parts involved; user authentication, and service registry.

The TGT says user is authenticated.

The ST says this service is allowed to use CAS for user authentication. Every service that wants to use CAS must be registered in the CAS services database.

Ray

On Tue, 2016-03-08 at 06:41 -0800, Yan Zhou wrote:

Hi there,

This is a beginner question, but I cannot seem to find answer anywhere.

Why is there a need for service ticket, it has to be validated every time a service is requested through CAS?  If user has a valid TGT, why would CAS server ever deny him trying to access a service?

Thanks,

Yan

[Fredrik Jönsson]

Not quite. The TGT is the token which authenticates the user to the CAS server itself, after initial sign in. It is used to get session tickets for individual services with which a user can authenticate to the services. Thus, the TGT does not have to be exposed to any other service than the CAS server (if configured properly) which is a matter of security.

The service registry validates which services are allowed to use the CAS server for ticket validation, but that is only by checking the URL passed as a service parameter, no tickets are involved.

/Fredrik

--

Fredrik Jönsson, M.Sc.

System Architect

KTH/UF/ITA/Infosys

E-mail: f...@kth.se

Phone: +46 8 790 6603

--
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.

[Fredrik Jönsson]

"Service ticket", not "session ticket". Sorry.

/Fredrik

--

Fredrik Jönsson, M.Sc.

System Architect

KTH/UF/ITA/Infosys

E-mail: f...@kth.se

Phone: +46 8 790 6603

[Zhou, Yan]

Hi Fredrik,

That sounds a good explanation.   So, one reason is that CAS does not want App to get hold of TGT for security reasons.

Why is service ticket valid only once?  Is that because CAS administrator can remove a service from the registered service list at any given time and revoke that service participating CAS SSO?

Yan

[Fredrik Jönsson]

I did not design the protocol, but to my understanding, the protocol is designed to work in a reasonably secure manner over insecure connections. The ticket is exposed as a URL parameter, possibly in clear text, over the network and most likely stored in logs on the server. Making it valid only once and with a very limited time span are remedies for replay attacks.

CAS makes no assumptions on how the client and server communicates, it does authentication, and authentication only. If the server and client wants to establish a session (e.g., with a session cookie) before or after authentication, that, and how, is entirely up to the application.

This is also another reason the TGT and ST are separate. The TGT can be replayed and requests using it must be made over a secure channel for security reasons, and CAS typically requires it. STs are designed so that it’s not a requirement for other services to use secure channels (though I’d still recommend it if possible).

/Fredrik

[Andrew Morgan]

Another important point - often the CAS server and the CAS client
application have different DNS domains. Cookies cannot be shared between
domains.

Andy