Axel, [
delete all his tickets from ticketRegistry but when he tried to login again he had an ticketGrantingTicketId and a service and then CAS create another ServiceTicket and the user result authenticated from CAS. I will modify the login-webflow.xml to check this but I think that CAS should do this change to the next release if all this is true. ] Since the underlying TicketGrantingTicket is removed from the registry or otherwise invalid, it doesn't matter whether and what ticketGrantingTicketId someone presents to CAS. Yes, since the ticketGrantingTicketId is not null, the request passes through this check in the flow, but CAS cannot issue a Service Ticket because there is no valid Ticket Granting Ticket from which to generate a Service Ticket. Even if CAS issued a Service Ticket (which it can't without a valid Ticket Granting Ticket), the service wouldn't be able to validate the Service Ticket, since without a backing Ticket Granting Ticket, there is no Principal to be revealed on validation. I don't think it's possible that CAS issued an unjustified validatable service ticket in the face of a present but invalid asserted ticketGrantingTicketId. How are you observing that behavior? Can you provide steps to replicate this against, say, JA-SIG's hosted CAS instance? https://www.ja-sig.org/cas/login I tried just now capturing my CASTGC cookie, logging out of CAS, using Firefox Web Developer plugin to re-add the cookie, and attempt to login to a service, and CAS executed the "right behavior" of prompting me to log in as if I had had no CASTGC cookie. As things actually play out, one passes through this step in the flow with a non-null ticket granting ticket ID and errors out later in the flow (silently), dropping to the login form where one has an opportunity to present username and password to again log in, establish a valid Ticket Granting Ticket, and obtain from that a Service Ticket to access the target service. This exact concern came up on a project I was working on with CAS and it turned out to be a non-issue as I've tried to describe here. I do agree that this is confusing, that it jumps out as a potential error on review of the login webflow, and so I do suggest that a comment about that state and why it works would be worthwhile in login-webflow.xml. Andrew Axel Mendoza Pupo wrote: > I think that in the login-webflow.xml this state > > <decision-state id="ticketGrantingTicketExistsCheck"> > <if test="${flowScope.ticketGrantingTicketId != null}" > then="hasServiceCheck" else="gatewayRequestCheck" /> > </decision-state> > > Should check against the ticketRegistry to see if the ticket that have > the ticketGrantingTicketId retrieved from the user cookie is not expired > or deleted. Because in my case I can force the logout of an user and > delete all his tickets from ticketRegistry but when he tried to login > again he had an ticketGrantingTicketId and a service and then CAS create > another ServiceTicket and the user result authenticated from CAS. I will > modify the login-webflow.xml to check this but I think that CAS should > do this change to the next release if all this is true. > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
