cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <coh...@gmail.com>
Subject Re: STS, OnBehalfOf token validation, SAMLTokenProvider
Date Mon, 21 Nov 2011 15:25:22 GMT
Hi Oli,

> I guess adding methods to an existing class is fine as a change from 2.5.0 to 2.5.1,
right?

IMO yes for this instance.

Colm.

On Mon, Nov 21, 2011 at 3:23 PM, Oliver Wulff <owulff@talend.com> wrote:
> Hi Colm
>
>>>>
> Sounds good. Could it be done without breaking backwards compatibility?
>
> +1 apart from the renaming. Could we just co-opt that new
> functionality into ReceivedToken instead?
>>>>
> I guess adding methods to an existing class is fine as a change from 2.5.0 to 2.5.1,
right?
>
> Thanks
> Oli
>
> ________________________________________
> Von: Colm O hEigeartaigh [coheigea@apache.org]
> Gesendet: Montag, 21. November 2011 15:04
> Bis: dev@cxf.apache.org
> Betreff: Re: STS, OnBehalfOf token validation, SAMLTokenProvider
>
> Hi Oli,
>
>> Due to separation of concern, wouldn't it make sense that the validation of OnBehalfOf
(and ActAs) is triggered in TokenIssueOperation?
>
> Sounds good. Could it be done without breaking backwards compatibility?
>
>> What do you think about this proposal:
>> ReceivedToken is renamed to something like ProcessedToken which contains informations
like:
>> - was it a token of ws-security header (like ReceivedToken), onbehalfof, actas
>> - successfully validated (it could be a token which depends on other constraints
to be fully accepted)
>> - original DOM element
>> - transformed DOM element (used if the token is passed by ref, also supported by
SAML spec)
>> - principal (mostly, you only need the principal to issue a new token)
>
> +1 apart from the renaming. Could we just co-opt that new
> functionality into ReceivedToken instead?
>
> Colm.
>
> On Fri, Nov 18, 2011 at 7:22 AM, Oliver Wulff <owulff@talend.com> wrote:
>> Hi all
>>
>> I've provided a patch for https://issues.apache.org/jira/browse/CXF-3923 which supports
to issue a SAML token based on the onbehalfof element.
>>
>> Some time back, I've  implemented a custom TokenProvider (also OnBehalfOf case)
where I had to validate the token in my TokenProvider implementation.
>>
>> Due to separation of concern, wouldn't it make sense that the validation of OnBehalfOf
(and ActAs) is triggered in TokenIssueOperation?
>>
>> Maybe we could use something similar to the ReceivedToken also for OnBehalfOf thus
the TokenProvider doesn't have to parse the token again?
>>
>> What do you think about this proposal:
>> ReceivedToken is renamed to something like ProcessedToken which contains informations
like:
>> - was it a token of ws-security header (like ReceivedToken), onbehalfof, actas
>> - successfully validated (it could be a token which depends on other constraints
to be fully accepted)
>> - original DOM element
>> - transformed DOM element (used if the token is passed by ref, also supported by
SAML spec)
>> - principal (mostly, you only need the principal to issue a new token)
>>
>> What do you think?
>>
>> Thanks
>> Oli
>>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com

Mime
View raw message