Possibly...there's a million different permutations of course...I
guess I'm mostly inclined to got with what's already establish if
possible, mostly to facilitate compatibility with existing clients.
Bill
On Thu, Apr 4, 2013 at 9:06 AM, Dmitriy Kopylenko <dkopyle...@unicon.net> wrote:
> How about dropping wrapper "authenticationSuccess" element altogether, as
> having all those another elements in the body would imply successful
> authentication?
>
> D.
>
> On Apr 4, 2013, at 8:54 AM, "William G. Thompson, Jr." <wgt...@gmail.com>
> wrote:
>
>> Dima,
>>
>> 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.
>>
>> * Are we planning on adding the new schema to the existing
>> cas/{service|proxy}Validate URLs? or creating new endpoints?
>>
>> * To what extend do we need backward compatibility with existing clients?
>>
>> * Would it be helpful to add protocol version attribute?
>> <cas:serviceResponse version="3.0"
>> xmlns:cas="http://www.yale.edu/tp/cas";>
>>
>> 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>
>>
>> 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>
>>
>>
>> Best,
>> Bill
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Apr 4, 2013 at 8:35 AM, Dmitriy Kopylenko <dkopyle...@unicon.net>
>> wrote:
>>> Folks,
>>>
>>> reading the latest protocol document found here
>>> https://docs.google.com/document/d/1l0o60mLfXF4bkQdwRSH4i6P-IJQki3-v-zyoOAjxDd4/edit#heading=h.33r393qqwd2i
>>> trying to make sense of the proposed XML response with attributes. As of
>>> currently, there are two types of attributes in the response - "cas
>>> attributes" representing authentication metadata and "user attributes".
>>> There is a sample XSD schema in the document as well as a sample response:
>>>
>>> <cas:serviceResponse xmlns:cas="http://www.yale.edu/tp/cas";>
>>> <cas:authenticationSuccess>
>>> <cas:user>username</cas:user>
>>> <cas:attributes>
>>> <cas:authenticationDate>20121116T12:10:23.0Z</cas:authenticationDate>
>>> <cas:longTermAuthenticationRequestTokenUsed>false</cas:longTermAuthenticationRequestTokenUsed>
>>> <cas:isFromNewLogin>false</cas:isFromNewLogin>
>>> <cas:memberOf>ROLE_USER</cas:memberOf>
>>> <cas:memberOf>ROLE_ADMINISTRATOR</cas:memberOf>
>>> <cas:userAttributes>
>>> <cas:firstname>John</cas:firstname>
>>> <cas:lastname>Doe</cas:lastname>
>>> <cas:title>Mr.</cas:title>
>>> </cas:userAttributes>
>>> </cas:attributes>
>>> <cas:proxyGrantingTicket>PGTIOU846788a9d...</cas:proxyGrantingTicket>
>>> </cas:authenticationSuccess>
>>> </cas:serviceResponse>
>>>
>>> I cannot figure out what are those "memberOf" attributes and what do they
>>> have to do with authentication metadata? Why not part of "user attributes"
>>> (if such "memberOf" attributes are available in the attribute repository for
>>> this particular principal). An any case, I fail to see the correlation
>>> between "memberOf" attribute and any particular authentication request and
>>> its generic metadata. May be someone could shed some light and provide a
>>> practical example.
>>>
>>> Thanks,
>>> Dmitriy.
>>>
>>> --
>>> 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:
>> dkopyle...@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: 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
