There is technically nothing that prevents 2 intimately cooperating services from passing the service ticket around. If service A hands off a ST it receives to service B, and service B uses service A's name as the "service" parameter, the CAS server will validate the ticket. The CAS server knows which tickets are associated with which service names, but it doesn't do any kind of verification to make sure that the requester of the /serviceValidate resource is actually that service.
That said, that would be a very strange thing for a client to do. The service ticket tells a service whether a user successfully authenticated to the service, the user ID, and possibly some attributes. I guess a "rogue service" that was registered with the server that could somehow steal STs from a neighbor service could gain access to attributes that only the neighbor could see. Thanks, Carl Waldbieser ITS Systems Programmer Lafayette College ----- Original Message ----- From: "Nate Klingenstein" <[email protected]> To: "Gilbert, Howard" <[email protected]> Cc: "CAS Community" <[email protected]> Sent: Monday, March 14, 2016 12:29:43 PM Subject: Re: [cas-user] Ticket Forwarding Howard, > All the client does is to know its own name, and the CAS server does the rest. <insert lame CA joke here and then revoke it> > it sort of didn’t matter how many hands the message passed through on its way > to the intended destination. Yes, that’s a key difference. CAS works more like SAML artifacts or OAuth. Are the contents of a request played to the login service by a client considered trusted or advisory, and how does the login service relay that information to the application? For instance, if a service sets the renew flag, is there a check of the authentication instant when the user comes back with a service ticket, or some other check, or could the wrong person with a ticket-granting cookie in hand remove that parameter and get a valid service ticket for the app? Do most client implementations behave similarly here? > The important piece from a security point of view is the underlying transport > model and not the service (in CAS) or audience (in SAML). In CAS, the CAS > server uses the service not only as the audience of the message but also as > the network address to which the browser is redirected. I see what you’re saying, but it’s not just that one piece. It’s that most of the security is in the transport model itself. Trying to answer my own question, it seems like the answer is “advisory”, which is the same as unsigned SAML and a fine answer. It all gets stuffed into the assertion in SAML, but the data for these checks in CAS never get serialized into a payload. The checks are made by the CAS server when the ticket validation query comes in, but there is no universal rule. There’s a lot of meta-state that the server tracks. Thank you again for your patience while I learn the protocol. Nate. -- 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/.
