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