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 [[email protected]] Gesendet: Montag, 21. November 2011 15:04 Bis: [email protected] 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 <[email protected]> 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
