The thing is I don't want to move it and create some transient thing so that we can check off "moved SAML out". If we've got a legitimate API that long-term we think is ideal, then I am all for it.
So I'm not against a proper API. I'm against creating something less than ideal so we can check off "grep for SAML returns zero results" :-) On Fri, Mar 1, 2013 at 11:43 AM, Misagh Moayyed <mmoay...@unicon.net> wrote: > 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 doesn’t > 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 don’t 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 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: > 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
