Oli, Normally in this kind of case, in your application code, you would do something like:
... get security token somehow .... proxy.getRequestContext().put(TOKEN_KEY, token) or similar to pass the token into the client proxy that is then used. Thus, no callback needed. The trick would be defining the token key correctly and creating the token itself. It would likely need to be a CXF SecurityToken object, but that's not hard to create. Dan On Friday, June 03, 2011 10:08:20 AM Oliver Wulff wrote: > Hi Colm > > After authentication happened within the web application I've got access to > the bootstrap token. There is no cxf message object created at this stage > because no processing occured at the web application yet. > > I see one option which involves two steps. A servlet filter writes the > bootstrap token (BT) to the thread local storage. The callback handler > implementation reads the BT from the tls and writes to the callback > object. > > The first step is very specific to the environment. Might it make sense to > define a TLS in CXF for the bootstrap token and a callback handler > implementation for this use case? > > Thanks > Oli > > ________________________________________ > Von: Colm O hEigeartaigh [cohei...@apache.org] > Gesendet: Freitag, 3. Juni 2011 12:12 > An: users@cxf.apache.org > Betreff: Re: Secured java web application calls secured web services with > identity delegation > > Hi Oli, > > Does the fix I commited for CXF-3565 meet your needs? > > https://issues.apache.org/jira/browse/CXF-3565 > > See for example this CallbackHandler implementation I added for > setting an OnBehalfOf element from the SecurityConstants.USERNAME > value: > > http://svn.apache.org/viewvc/cxf/trunk/rt/ws/security/src/main/java/org/apa > che/cxf/ws/security/trust/delegation/WSSUsernameCallbackHandler.java?view=m > arkup > > The CallbackHandler has access to the current message. You can load > the callback handler via the "onBehalfOf" property of the STSClient. > > Colm. > > On Fri, Jun 3, 2011 at 10:58 AM, Oliver Wulff <owu...@talend.com> wrote: > > Hi there > > > > Let's assume a tomcat based web application is secured either with SAML-P > > or WS-Federation (passive requestor profile). The web application is > > calling web services on behalf of the original authenticated user. The > > web services have an IssuedToken assertion and expect a SAML 2.0 token - > > only Bearer subject confirmation method is applicable here. > > > > The web application (CXF web service consumer) must communicate with an > > STS to get the SAML token issued on behalf of the original user. If > > SAML-P oder WS-Federation is used, Tomcat has access to the original > > token (or bootstrap token). So, the bootstrap token is put in the > > WS-Trust RST in the OnBehalfOf element. The question is how can we let > > CXF know that it acts as an intermediary and set the bootstrap token > > somehow? > > > > CXF already provides the option to access the incoming CXF message when a > > new outgoing message is created: PhaseInterceptorChain.PREVIOUS_MESSAGE > > > > In the above case, there is no PREVIOUS_MESSAGE because the incoming > > request is a web application request (HTML/HTTP). Therefore, the > > IssuedTokenOutInterceptor should provide an API/callback to let him know > > the bootstrap token. > > > > A custom servlet filter might then be able to read the incoming token > > from the TLS or Http Session and set it using the CXF API. The scope > > would be the current thread I think. I also think the thread which > > processes the web application request is the same as the > > IssuedTokenOutInterceptor even you use WS-RM or one-way. > > > > What do you think? > > > > Thanks > > Oli > > -- > Colm O hEigeartaigh > > http://coheigea.blogspot.com/ > Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
