I share Adam's perspective here. The big sticking point had been backward compatibility with current CAS clients. Initially the thought was to simply add attributes to the current validation end-point as so many deployers have done in practice. But given the issue of multi-valued support and wanting to "get it done right", perhaps we should revisit the idea of a new versioned validate end-points? This would be consistent with what was done in the past with CAS1/2 protocol.
Current endpoints: /validate - CAS 1.0 protocol /serviceValidate & /proxyValidate - CAS 2.0 protocol Proposed endpoints: /v3/serviceValidate % /v3/proxyValidate - CAS 3.0 protocol? Best, Bill On Tue, Nov 5, 2013 at 4:56 PM, Adam Franco <afra...@middlebury.edu> wrote: > On Tue, Nov 5, 2013 at 8:11 AM, Marvin Addison <marvin.addi...@gmail.com> > wrote: >> >> > I'm not saying that the 4.0 must support multi-valued attributes. >> >> I believe it would be a big mistake to fail to provide some reasonable >> support for multi-valued attributes out of the box. Many if not most >> directory attributes are naturally multivalued, notably role data used >> for authorization; lack of support for that case would likely invite >> the sorts of one-off customizations that we presumably want to >> curtail. > > > As a heavy user of multi-valued attributes (mostly LDAP MemberOf DNs) and > the author of the phpCAS attribute support code, I'd like to second Marvin's > suggestion that proper multi-valued attribute support will be critical to > standardizing much of the usage of CAS Protocol v3 and CAS Server 4.0. > > Recently more and more SAAS vendors we contract with are beginning to > support CAS authentication. With the exception of platforms implemented in > PHP and using phpCAS, all vendors have stumbled on access control and > name/email population based on released attributes due in part to the lack > of support in their CAS client libraries and in part due to the lack of > documentation on attribute release in the protocol. Due to the lack of a > standardized method for attribute release, we are forced to provide vendors > with our own documentation of our own particular way of doing attribute > release. Vendors in turn must add this support as a customer-specific > customization to their software rather than as a general improvement that > they can provide to all customers. > > The sooner CAS Protocol v3 and CAS Server 4.0 support both single and > multi-valued attribute release, the sooner we can begin pushing all users to > the new protocol and get rid of our numerous incompatible customizations. > > > ** Encoding of multi-valued attributes ** > > The latest version of the CAS 3 protocol simply states that: > > it is recommended to form custom attributes as <cas:attributes > name="NAME">VALUE</cas:attributes>. > > I suggest that this language be extended to recommend something like: > > Multiple values for the same attribute name should be formed as > <cas:attributes name="NAME">VALUE1</cas:attributes> > <cas:attributes name="NAME">VALUE2</cas:attributes> > > Making these multiple values proper XML elements is absolutely necessary to > ensure compatibility between implementations in a variety of environments. > Compatibility will be very difficult to achieve if implementations are > forced to interpret the particularities of JSP collection/string > serialization for arbitrary attribute values. > > Best, > Adam > > -- > > Adam Franco > Senior Software Engineer - Web Applications > Library and Information Services > Middlebury College > Middlebury, VT 05753 > afra...@middlebury.edu > 802.443.2244 > > > On Tue, Nov 5, 2013 at 10:32 AM, Fredrik Jönsson <f...@kth.se> wrote: >> >> A couple of thoughts. First of all the attribute release is a most >> welcome addition to the CAS protocol and I really look forward to use >> it. >> >> I would think carefully about the road ahead, and as I see it there are >> three options: >> >> 1. "Accidentally" print multi-value attributes as a list of sorts which >> is currently done, and the Java client likewise "accidentally" supports >> and interpret as a list. >> >> 2. Explicitly not support multi-value attributes and either remove them >> or print the first item in the list only pretending that it is a single >> value. >> >> 3. Actually implement, in the server at least, as suggested in the >> specification. >> >> I'd recommend sticking to the specification in the protocol draft and >> use any of the last two options. I agree that multi-value attributes are >> common, indeed we have such that I would most definitely want to use and >> would prefer support as specified, but I could wait for another >> iteration. I think that the current RC2 server behavior is risky, since >> implementations may come to depend on a de facto undocumented behavior >> and blow up at a later upgrade which prints multi-value attributes some >> other way. The server interface is the XML output and not the Java >> client library. >> >> Regards, >> /Fredrik >> >> On tis, 2013-11-05 at 08:11 -0500, Marvin Addison wrote: >> > > I'm not saying that the 4.0 must support multi-valued attributes. >> > >> > I believe it would be a big mistake to fail to provide some reasonable >> > support for multi-valued attributes out of the box. Many if not most >> > directory attributes are naturally multivalued, notably role data used >> > for authorization; lack of support for that case would likely invite >> > the sorts of one-off customizations that we presumably want to >> > curtail. >> > >> > M >> > >> >> >> -- >> You are currently subscribed to cas-dev@lists.jasig.org as: >> afra...@middlebury.edu >> >> 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
