> I'm now hitting logout page... > > WHO: audit:unknown > WHAT: TGT-4-cGhcNvYZmjZCKIQRrvo4Pe0KlP7wu3lc7Pj5emDjLiKQXbYXsJ-dev.mydomain > ACTION: TICKET_GRANTING_TICKET_DESTROYED > > => Perfect > > WHO: <DN of my certificate> > WHAT: supplied credentials: <DN of my certificate> > ACTION: AUTHENTICATION_SUCCESS > > WHO: <DN of my certificate> > WHAT: TGT-5-bjIrzp2Vo1ECysI3uJqLaZmzyvlElfIN7s6tsdIZAZdYn4aQNa-dev.mydomain > ACTION: TICKET_GRANTING_TICKET_CREATED > > => Hum, this is not that I intended to do !
This likely happens because your logout URL is also under the same servlet container config that requests a client certificate. That's not enough to trigger the login Webflow in itself, but I would imagine that there is some resource that the browser is making a GET to such that the login Webflow is executing following the extraction of the cert by the container. That would meet the criteria for a non-interactive authentication, and generate a TGT as your audit logs indicate. The question remains about what, in particular, is triggering the login Webflow. I would argue that every X.509 deployment should be configured with two ports, one that is configured to want or require a cert to support the login Webflow, and all other requests. We do this and it has worked exceptionally well. M -- 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-user
