> 1) each application is a point of failure; to avoid that partially, logout > requests can be parallelized, though it removes the advantage 3)
I was thinking Javascript/AJAX as default with a fallback to 302-mediated w/timeouts if scripting is unavailable. > 2) each CAS client needs to be updated to deal with this new mechanism > (whereas logout urls can exist by default in client applications using Spring > Security, Shiro...) Based on a preliminary analysis, I believe the change to "official" clients will be relatively small. Taking the Java client as a concrete case, we just have to tweak SingleSignOutFilter to accept an additional param (RelayState), and when present, send a response back to the server. > 3) it's easier to have just one logout url for each application, than a lot > of redirections with SAML requests and responses. The benefit here of getting some kind of response is that it provides information on the authenticated state of the application (signed in, signed out, indeterminate), which we could communicate to the user. That has a very high usability value, and is worth some wrangling to implement. I believe the implementation is fairly straightforward and could be made to be reasonably robust. I think we could start to sketch out the SAML solution and find out fairly quickly whether I'm right. M -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
