Hi Marvin, When developping the front SLO, I'm facing a major issue and have two questions :
1) ISSUE : the destroyTicketGrantingTicket method In the destroyTicketGrantingTicket method of the CentralAuthenticationServiceImpl class, there is a call to the expire() method which marks the ticket expired and *performs the back channel SLO*. This method is used in : - AbstractNonInteractiveCredentialsAction - AuthenticationViaFormAction - TicketGrantingTicketResource (REST API). It means that a back channel logout can be performed in these classes (when a TGT is deleted in the REST API or when the creation of the ST fails in the two other classes). Is this the expected behaviour (performing a back channel SLO) ? I think so... How can a perform a front channel SLO here ? Or will the front channel SLO only available when calling the /logout url ? 2) Question : HTTP caching The LogoutController class is based on the AbstractController class with a setCache(0) call in the constructor. It means that the appropriate headers are added on the logout page or redirection to prevent caching. I plan to keep this behaviour. 3) Question : SAML messages compression You use a deflater to compress the SAML messages sent for front SLO. Is it really necessary ? It means that the CAS client will need to evolve to deal with it, right ? Is this compression mandatory or just an optimization ? Should we also compress SAML messages for the back channel SLO ? Thanks. Best regards, Jérôme -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
