Tom, yes, exactly. An administrator may not have ready access to the TGT identifier of the TGT to be terminated.
That is, the request: "Terminate all SSO sessions active for user 'apetro'." seems more plausible than the request "Terminate TGT with identifier TGT-656-2342342-cas1". So offhand I think the current REST APIs aren't quite sufficient. They might well be the APIs that something else calls to effect the TGT termination, but I think there's a need for something else to front it to do the translation from the business need to the TGT termination command. Andrew On Wed, May 29, 2013 at 2:21 PM, Tom Poage <[email protected]> wrote: > On May 29, 2013, at 11:05 AM, Marvin Addison <[email protected]> > wrote: > > It just occurs to me that strictly speaking we already have support for > the latter. The RESTful API exposes the following method: > > > > public void destroyTicketGrantingTicket(final String > ticketGrantingTicketId) {...} > > The REST API sounds promising, though for the case I had in mind, being > able to identify and invalidate TGT(s) by principal name would be best. > Optionally, perform 'logout' call backs to registered services. > > Given warnings on the corresponding web page, we might consider deploying > an additional node in the CAS cluster, not exposed to the outside world > (cf. load balancer), whose principal purpose would be to expose the API to > security apps (kind of a waste of resources tho'). That, or protect the API > paths using e.g. public key. > > Tom. > -- > 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 > > -- 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
