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