>From the dev call the other week, the remaining sticking point for 4.0GA was multi-valued attributes and backward compatibility for existing CAS clients. Adding a new protocol specific endpoint, /p3/serviceValidate resolves this issue. (/p3/ for "protocol 3" and avoiding conflict with existing REST endpoints, /v1/...)
Current endpoints: /validate - CAS1 protocol /serviceValidate & /proxyValidate - CAS2 protocol (leave these unchanged) Proposed CAS3 protocol endpoints: /p3/serviceValidate & /p3/proxyValidate - CAS3 protocol with multi-valued attributes As Adam pointed out this provides a very viable and reasonable path for deployers: 1. Folks doing attribute release in /serviceValidate today can continue that practice in custom overlays 2. Folks using clients that support multi-valued attributes release can use /p3/serviceValidate 3. Folks can transition back to stock end-points when ready +1 for reverting /serviceValidate to CAS2 protocol/CAS3.x release behavior (deployers can continue to overide as required). This ensures backward compatibility for all current CAS clients. +1 for new /p3/serviceValidate for CAS3 protocol multi-value attribute release. This provides optional enhanced features for clients that support it. Regarding JSON and other protocol enhancements, perhaps that should wait until 4.0GA is out the door. Best, Bill On Wed, Nov 27, 2013 at 4:00 AM, Jérôme LELEU <lel...@gmail.com> wrote: > Hi, > > The JSON endpoint is a new proposal from myself, it's completely open to > discussion... > > During the conf call, we said that the attributes support must be > thouroughfully tested. I'm convinced that single value attributes will fit > with all CAS clients, conversely, it seems that multi values attributes > won't be supported by all clients. > > Updating a new endpoint is pretty simple for CAS deployers as they will > benefit quickly from the update whereas the creation of a new endpoint is a > mid-term gain as CAS clients must be upgraded and then redployed in > applications. > > @Bill : what's the feedback about the tests of the single/multi value(s) > attributes support in 4.0 ? > > Thanks. > Best regards, > Jérôme > > > > > 2013/11/25 Misagh Moayyed <mmoay...@unicon.net> >> >> How about a small alternate version of what you are proposing? >> >> For the current scope of 4.0: >> - Keep a /v3/serviceValidate endpoint: return attributes; both single and >> multi-valued the latter being more of a defect I'd say that needs to be >> fixed. To keep in sync with the protocol, we would also consider adding >> authentication attributes to the payload. >> >> For the scope of 4.x: >> - Work on JSON attributes and complex objects in the payload, which seem >> to be more like new features to the protocol. >> >> Also, slightly confused here (and this may have been discussed on the last >> @cas-dev call). Now that I review this once more, what constitutes creating >> a new v4/ endpoint? I'd assume changes to the protocol. If so, would it then >> be that attributes in JSON would then be provided via a /v4/serviceValidate >> since the change impacts protocol? Seems a bit messy to me to maintain this >> path. >> >> Ideally, I'd think that it's simpler (and easier on the protocol) if we >> stick to the current endpoint and just make sure, as we go through rounds of >> integration testing with the official clients, that they are able to at >> least not break down, if not directly support the new functionality. That >> may be too greedy though. >> >> ________________________________ >> From: "Jérôme LELEU" <lel...@gmail.com> >> To: cas-dev@lists.jasig.org >> Sent: Sunday, November 24, 2013 1:37:14 AM >> Subject: Re: [cas-dev] CAS Protocol v3 Status >> >> Hi, >> >> I'm very hesitating on this. >> In fact, I think that we have two different needs we must not mix : >> >> 1) the first one is to capture a common practice than almost CAS deployers >> implement on their own : return attributes on /serviceValidate endpoint. >> It's an improvment with little risk as it's already supported by CAS >> clients. It's almost something that should have existed from the creation of >> the endpoint. CAS deployers expect a lot this evolution. It perfectly fits >> in the 4.0 roadmap. >> A short-term gain and a none breaking change at the same time. >> >> 2) the second one is the necessity to upgrade our profile support : the >> previous common customization to return attributes does not handle properly >> multi-values attributes. That's a weakness we must fix. But, as I proposed, >> we should also return more authentication attributes : like isFromNewLogin, >> the authentication date and the last (TGT) updated date as these can be used >> to manage the remember-me feature properly. >> But it's still not enough and it's far from what new "identity providers" >> propose. And I'm the first one that should never forget that because of the >> OAuth support. For example, the profile returned by Facebook has attributes >> which are very complex objects (not only lists or maps of primitive types) : >> https://github.com/leleuj/pac4j/blob/master/pac4j-oauth/src/main/java/org/pac4j/oauth/profile/facebook/FacebookProfile.java. >> The way I found to make that work with our current V2 endpoint was to >> serialize complex objects in JSON and deserialize them on client side (we >> had also this discussion with Misagh -> >> https://issues.jasig.org/browse/CAS-1301). I also remember this excellent >> idea from Dmitriy proposing to create a new JSON endpoint. We would of >> course need to update all CAS clients to support this new endpoint. >> More work/changes for a great mid-term improvment. >> >> So I change my mind (sorry about that) : >> - I would keep the current V2 endpoint upgrade (to return attributes) for >> 4.0 >> - I would create a new endpoint : /3/serviceValidate url, returning JSON >> to be able to handle multi-values attributes but also more complex objects >> and returning authentication attributes as well. For 4.0 ? >> >> What do you think ? >> >> Thanks. >> Best regards, >> Jérôme >> >> >> >> 2013/11/22 Marvin Addison <marvin.addi...@gmail.com> >>> >>> > shouldn't we revert to the original CAS >>> > 2.0 endpoint and create this new v3 endpoint right now in a 4.0-RC3 ? >>> >>> +1 >>> >>> > And if our strategy is to make CAS clients adapt to new endpoints (and >>> > not >>> > the opposite), couldn't we add also to this new v3 endpoint the >>> > authentication attributes required for remember-me (isFromNewLogin, >>> > authenticationDate, maybe a lastUpdatedDate...) >>> >>> Seems equivalent to I asked about a while back w/r/t proxy, which was >>> rejected. I'm not opposed to meaningful protocol v3 enhancements that >>> make sense, but it's probably true that it's not consistent with our >>> release policy if we're targeting these changes for 4.0. I'm not one >>> to let policy get in the way of positive change; I'm open to tweaking >>> policies if we wanted more flexibility now and going forward. >>> >>> M >>> >>> -- >>> You are currently subscribed to cas-dev@lists.jasig.org as: >>> lel...@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: >> lel...@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: wgt...@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
