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 don’t 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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
