> 3. SLO applies to TGTs their associated STs, as well as their associated PGTs > and their STs, etc.
My vote is for #3 since it appears feasible and is most consistent with expected behavior regarding SLO. Based on my code review, it should be fairly straightforward to implement. We could modify TicketGrantingTicketImpl#logOutOfServices() to walk up the ticket chain to the root and at each ticket iterate over services and issue the logout. It's worth considering whether PT endpoints could reasonable receive an SLO callback message. > I would also expect some kind of guarantee of delivery, e.g., that the server > retried the SLO request for at least some time until receiving 200 or 404. I think it's well accepted that guarantees of delivery are not feasible in practice. If a service endpoint is unreachable (network failures, service outage, etc), you have a handful of unpalatable choices: - Give up immediately and report a failure - Block indefinitely on the IO request to the endpoint until it comes back - Implement an asynchronous retry loop In the first case you didn't try very hard, so it's hard to argue "best effort" delivery. The latter two seem consistent with best effort, but tie up precious server resources. More importantly in terms of user experience and security policy, they take time such that you have to balance trying hard enough and taking too long such that the answer is meaningless by the time it comes back. In summary, it's hard to provide guarantees. 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-dev
