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<https://github.com/Jasig/cas/blob/master/cas-server-protocol/3.0/cas_protocol_3_0.md#head_appdx_a>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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
