Well, for the most part the benefit is consistency. I do agree that the implementation is sending and parsing a small piece of XML that doesnt have much to do with SAML per se, but if the idea is to move SAML out of core as much as possible then I figure separating concerns would be in order and it would keep the core module small. I dont have offhand a hard use case for what the public API could potentially do, but this extension point might even become beneficial, if the nature of SLO was to be implemented differently, as the discussion currently carries on.
No strong opinions on this really, but an incremental approach to perhaps convert the core to be more about SPIs rather than hard implementations I think is favorable. This is an idea that folks at the recent UnConnference were kicking around (Bill hinted at this of course in a separate thread) and this modest improvement is somewhat in alignment with that idea. -Misagh From: Scott Battaglia [mailto:scott.battag...@gmail.com] Sent: Friday, March 01, 2013 8:16 AM To: cas-dev@lists.jasig.org Subject: Re: [cas-dev] SAML logout request & SLO Just curious as to what benefit we get at this particular moment from moving these? Its strings that look like SAML and a thing that generates date's in a specific format that matches what SAML does. Both are lightweight and tightly integrated (for better or worse). I'm not sure we need a stop-gap of a new interface (that then sort of becomes a public API) just so we can say that if you do a string search in core on SAML, you get no results back. On Fri, Mar 1, 2013 at 10:06 AM, Misagh Moayyed <mmoay...@unicon.net> wrote: If I understand the context correctly, I dont suppose our intention was to get rid of the logout request but to simply move it over. Agreed that the request isn't strictly protocol based but it's awfully SAML looking! and then there's also the SamlDateUtils class that lingers still in core. So with the goal of keeping core as "clean" as possible, may I propose the following? 1. We move over the SamlDateUtils to the saml module 2. We abstract away the submissions of the logout request into an interface, of which a default and current SAML-looking implementation might exist in the saml module 3. A dependency is declared in CAS-webapp on the SAML module to wire everything up together 4. Leave the clients as they are now, such that they would still expect the same SLO format and syntax. Extension points may be provided in the future to do some "clean up". Does that make sense? Needless to say, I am more than glad to assist with the dev/QA effort of this proposal. Regards, -Misagh > -----Original Message----- > From: jleleu [mailto:lel...@gmail.com] > Sent: Thursday, February 28, 2013 3:04 AM > To: cas-dev@lists.jasig.org > Subject: [cas-dev] SAML logout request & SLO > > Hi team, > > Some times ago, we talked about SAML support and its extraction from core > into a separate module. It's done (CAS-1188), but there is one element > remaining in core : the SAML logout request. > > I checked the main CAS clients : Java, PHP and .Net to see how they handle > the SAML logout requests. All clients expect XML requests and the tag > SessionIndex or samlp:SessionIndex. > It is therefore very difficult to get ride of the SAML logout request > without > impacting strongly the CAS clients. We could send smaller XML requests > which > can be compliant with clients, but it wouldn't be a real improvment. > > So I think we should keep the SAML logout request "as is" (custom code in > the > core). I consider the SAML logout request more as a logout request in XML > format than a real implementation of the SAML protocol. > > What do you think ? > > --- > > About SLO more generally, I think that our current SLO mechanism is > somehow > limited. It works well for web sites with reasonable internet traffic. > At my company, we have more than a hundred web sites integrated with our > CAS > server and 99% of them are clusters because of the high incoming traffic > and > the fact we want redundancy. > We choose clusters with session affinity to scale well, but if we want to > handle properly SAML logout requests from the CAS server, we need to share > sessions accross the cluster which is not good for scalability and > requires > more work for setup. > So I implement a custom front-channel SLO. Each CAS service can be > configured > with a logout url, which will be called from a hidden image in the CAS > logout > page. > > Is this a solution that makes sense to you ? > > Thanks. > Best regards, > Jérôme > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > mmoay...@unicon.net To unsubscribe, change settings or access archives, > see > http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org as: scott.battag...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org as: mmoay...@unicon.net To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- 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
