Another important point - often the CAS server and the CAS client
application have different DNS domains. Cookies cannot be shared between
domains.
Andy
On Fri, 11 Mar 2016, Fredrik Jönsson wrote:
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
11 mars 2016 kl. 15:14 skrev Zhou, Yan <[email protected]>:
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
On 3/10/2016 2:08 PM, Fredrik Jönsson wrote:
"Service ticket", not "session ticket". Sorry.
/Fredrik
--
Fredrik Jönsson, M.Sc.
System Architect
KTH/UF/ITA/Infosys
E-mail: [email protected]
Phone: +46 8 790 6603
10 mars 2016 kl. 20:07 skrev Fredrik Jönsson <[email protected]>:
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: [email protected]
Phone: +46 8 790 6603
10 mars 2016 kl. 19:41 skrev Ray Bon <[email protected]>:
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
--
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 [email protected].
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
--
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 [email protected].
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
--
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 [email protected].
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
