Ok. I think I got it now...thanks for catching us (me :) up on the thread. Let me see if I can summarize:
* CAS Protocol 3.0 rev is simply meant to capture current, in-the-field, practice that has evolved in CAS3 and the respective CAS clients. (e.g. the <cas:attributes> customization) * Most CAS clients (including the older Spring CAS client) already support arbitrary attributes under <cas:attributes>. (Additionally there was some consensus on cas-dev regarding the desire to indicated authN metadata vs user attributes for the evolving LOA feature...thus the addition of the embedded <cas:userAttributes> to the <cas:attributes> block as well as tags for authN metadata in the example response. All of these attributes are optional since they appear in <cas:attributes> and not likely to be implemented until LOA is truly worked out. Perhaps the example response could be simplified to better reflect current practice and to avoid confusion?) For the CAS Protocol 3.0 rev, all we are saying is that <cas:attributes> and anything under it is optional and that clients may make those available (likely via a principal object). Yes? So for https://issues.jasig.org/browse/CAS-1283 all we need to do is add something simliar to CAS-655 and verify it works with current clients? Best, Bill On Thu, Apr 4, 2013 at 10:32 AM, Robert Oschwald <robertoschw...@googlemail.com> wrote: > >> >> At first glance this looks like possibly a "bug" in the sample >> response. In any case, it deserves some discussion as there are >> probably some details to work out. >> > > Not a bug, it's a feature :-) > I added userAttributes to distinguish between user and authentication > attributes as discussed on the cas-dev mailing list. > See https://lists.wisc.edu/read/messages?id=23100350#23100350 and > particularly > http://www.mail-archive.com/cas-dev@lists.jasig.org/msg03812.html by Jerome. > > >> * Are we planning on adding the new schema to the existing >> cas/{service|proxy}Validate URLs? or creating new endpoints? > > Specification 3.0 covers the existing features, so yes it is for the current > validate urls. > > >> >> * To what extend do we need backward compatibility with existing clients? >> > > As much as possible for now. > As the attributes are defined as optional (and user-extendable, see Appendix > A), I strongly recommend to stay with the most common schema used by CAS > Client today. > > In spec 4.0, we can change that if we have a need to do so. > The attribute schema part I added is the one defined in > https://issues.jasig.org/browse/CAS-655 > It was in the CASUM manual, but the CASUM page for validation attributes > (phpCAS) was changed slightly to flat <cas:attribute> values. > At least for us, we use an older Spring CAS Java client iin one larger > installation which expects the data as described in CAS-655. > phpCAS supports many flavors of attributes ("JASIG Style", "rubyCAS Style" to > name a few) it seems. See > Older Java CAS Clients support only the "JASIG style", therefore I decided to > describe it in the current 3.0 WIP document. > >> * Would it be helpful to add protocol version attribute? >> <cas:serviceResponse version="3.0" >> xmlns:cas="http://www.yale.edu/tp/cas";> >> > > +1 > >> I tend to agree with your assessment and wonder if we could make this >> more simple with the follow approach: >> * use existing tags as they are (this seems already to be the case, >> e.g. <cas:user>) >> * any new authentication metadata is just a new tag right under >> <cas:authenticationSuccess> >> * any user attributes go under <cas:userAttributes> >> > > As said, currently we might need <cas:attributes> to not break existing > (older) clients. > As attributes in service validate are not defined in the SPEC (one of the > main reasons I started working on 3.0), we have some sort of dilemma here to > figure out what is best to not break existing installations. > If we release the spec and add these attributes in one of the next CAS > releases, I'm afraid of breaking existing CAS attribute modifications if we > do not take care on this issue. > > > >> Perhaps something like this: >> >> <cas:serviceResponse version="3.0" xmlns:cas="http://www.yale.edu/tp/cas";> >> <cas:authenticationSuccess> >> <cas:authenticationDate>20121116T12:10:23.0Z</cas:authenticationDate> >> >> <cas:longTermAuthenticationRequestTokenUsed>false</cas:longTermAuthenticationRequestTokenUsed> >> <cas:isFromNewLogin>false</cas:isFromNewLogin> >> <cas:proxyGrantingTicket>PGTIOU846788a9d...</cas:proxyGrantingTicket> >> <cas:user>username</cas:user> >> <cas:userAttributes> >> <cas:memberOf>ROLE_USER</cas:memberOf> >> <cas:memberOf>ROLE_ADMINISTRATOR</cas:memberOf> >> <cas:firstname>John</cas:firstname> >> <cas:lastname>Doe</cas:lastname> >> <cas:title>Mr.</cas:title> >> </cas:userAttributes> >> </cas:authenticationSuccess> >> </cas:serviceResponse> >> > > +1, but I strongly recommend to make this change in the 4.0 spec, later. > > > > Robert > > > > > > -- > 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
