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 <owu...@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 [cohei...@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 <owu...@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
