Hi Robert, No problem for the delay. No pressure...
>From my point fo view, we have data : authentication and user information and we have formats to send this data : plain text (CAS1), xml (CAS2), SAML, JSON... I think we need the distinction between user and authentication attributes. I prefer to be too permissive on user attributes definition in XSD else it would be hell for CAS deployers to update XSD every time they want to return a new attribute. The SAML validation should be part of the spec, but marked optional as we decided some times ago. Making SAML optional makes me wonder about the SAML validation in CAS client : make it optional also ? split the CAS client in multiple specific clients ? Adding JSON validation in the spec was just a proposal : we need to decide on this. For LOA, I'm not very optimistic in our ability to do it quickly so I think it will be out of scope for this spec revision. Best regards, Jérôme On Wednesday, November 14, 2012 10:30:49 AM UTC+1, Robert Oschwald wrote: > > Jérôme, > > thanks for your comments. I appreciate it. I'm late in replying because I > was on vacation and be busy currently with 2 big projects. > > All obvious points you mentioned I will introduce. > Some I think we need to discuss further: > > Attributes: > I added an "xsd:attributes" element because that is widely used (e.g. in > Java CAS client) and did not distinguish between user and authentication > attributes because of this. > Maybe it would be a good idea to encapsulate all user attributes in an own > "userAttributes" parent within the "attributes" Element. I think of it a > bit more. > > User attributes xsd restriction: > When we would allow any user attribute elements in the xsd we define in > the spec, we cannot restrict the sub structure of them (e.g. <xsd:any /> > allows arbitrary sub structures. You cannot restrict to single level > elements in xsd) > Also, as we define a CAS specification, we should set the schema > restriction to the common, base elements needed so any CAS client or server > can be implemented compliant to this specification. > This does not mean that one is not allowed to extend the response schema > to his needs in the concrete implementation (thats what we and others have > done in the past, eg for rememberMe notification support). > What do you think? > > samlValidation: > Regarding samlValidation, I would add it to the spec but mark it as > optional, as this is the standard validation way this times (e.g. in CAS > Client, Spring Security). I'm absolutely open to a discussion here. > > jsonValidate: > I wasn't aware that currently external extensions should be part of this > spec. I think jsonValidate is of great value, but shouldn't we also add > this feature to JASIG CAS code base, so we support all the features > described in the spec and document it in the CAS user manual ootb? > > Regarding LOA: > I know this is an ongoing task to implement it currently. I'm not into LOA > that deep, so I would appreciate if you can add this chapter (you got write > access to my page) or give me some pointers to documentation so I can add > it. > > As I'm in 2 big projects currently, it will take some time until I can > work further on the spec. Please be patient with me. > > Best regards, > Robert > > Am 23.10.2012 um 13:08 schrieb jleleu <lel...@gmail.com <javascript:>>: > > > Hi, > > > > It'a great work Robert, changing the CAS protocol has a much wider scope > than I thought. > > > > My comments : > > > > - /login as credential requestor : I don't see the "method" parameter to > define how to do the redirection to the requested service after successfull > authentication (method=POST) > > > > - parameters for username/password authentication : OK for the > rememberMe parameter > > > > - "service" parameter on logout : OK, but you need to add that for > security reasons, the "service" parameter must match a configured CAS > service > > > > - single sign out : there is nothing about front channel SLO, we should > maybe anticipate this... > > > > - /serviceValidate : I don't see authenticationDate and > longTermAuthenticationRequestTokenUsed attributes as *user attributes*, > they are authentication attributes from my point of view. They need to be > returned outside the user attributes tags. For the user attributes, I > wouldn't be so retrictive and allow user attributes of any name. > > > > - /samlValidate : we said that the SAML validation will become an > optional module (CAS-1188) : should it be part of the spec ? At least, the > optional aspect of this validation should be added in the spec. > > > > - /jsonValidate : you don't mention this new endpoint url, Dmitriy won't > be happy here ;-) > > > > - I don't see anything about loa. Is it on purpose ? > > > > I think that this topic will also deserve a conf call to reach an > agreement some day. > > > > Are steering commitees still happening some times ? I think it would be > the right place to focus on these topics : LOA, CAS protocol revision... > > > > Best regards, > > Jérôme > > > > -- > > You are currently subscribed to cas...@lists.jasig.org <javascript:>as: > roberto...@googlemail.com <javascript:> > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > > -- > You are currently subscribed to cas...@lists.jasig.org <javascript:> as: > cas-dev-gar...@googlegroups.com <javascript:> > 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
