You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Oliver Wulff <ow...@talend.com> on 2011/11/18 08:22:09 UTC
STS, OnBehalfOf token validation, SAMLTokenProvider
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
AW: STS, OnBehalfOf token validation, SAMLTokenProvider
Posted by Oliver Wulff <ow...@talend.com>.
OK, I've raised JIRA:
https://issues.apache.org/jira/browse/CXF-3928
________________________________________
Von: Colm O hEigeartaigh [coheig@gmail.com]
Gesendet: Montag, 21. November 2011 16:25
Bis: Oliver Wulff
Cc: dev@cxf.apache.org
Betreff: Re: STS, OnBehalfOf token validation, SAMLTokenProvider
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 <ow...@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 <ow...@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
Re: STS, OnBehalfOf token validation, SAMLTokenProvider
Posted by Colm O hEigeartaigh <co...@gmail.com>.
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 <ow...@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 <ow...@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
AW: STS, OnBehalfOf token validation, SAMLTokenProvider
Posted by Oliver Wulff <ow...@talend.com>.
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 <ow...@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
Re: STS, OnBehalfOf token validation, SAMLTokenProvider
Posted by Colm O hEigeartaigh <co...@apache.org>.
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 <ow...@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