>>> TLS's are generally a bad idea. There are a bunch of cases where the message can flip threads and then those TLS values would be lost. >>> I agree on this. I was thinking of doing that in the setup phase where the thread should be the same which matchs with what you say in 2).
Thanks Oli ________________________________________ Von: Daniel Kulp [dk...@apache.org] Gesendet: Dienstag, 7. Juni 2011 21:35 An: users@cxf.apache.org Cc: Oliver Wulff; cohei...@apache.org Betreff: Re: AW: AW: Secured java web application calls secured web services with identity delegation On Monday, June 06, 2011 2:01:53 PM Oliver Wulff wrote: > Hi Dan > > I'd like to avoid that the application developer has to write any security > related code. Instead, some configuration can be set to delegate the > identity. > > The enhancement https://issues.apache.org/jira/browse/CXF-3565 allows to > write a callback which is triggered if OnBehalfOf property is set and > which can read the token from a custom TLS. Well, you are beginning to really tip-toe the line between what a framework like CXF is providing and what an Application developer should be providing. Getting the information into the TLS really is something somewhat application specific, I think. > An option would be that we provide as part of CXF such kind of callback > which reads the token from the TLS. TLS's are generally a bad idea. There are a bunch of cases where the message can flip threads and then those TLS values would be lost. Thus, a solution like this really involves a bunch of things: 1) Servlet filter or similar that would populate the TLS. However, it's likely better to just stick the value as a http request property or something. 2) An interceptor that would live VERY early in the chain that would grab the TLS value and copy it into a property on the Message. In this case, the interceptor could easily map it into the existing "ws.security.*" keys on the message that the runtime is already looking for. 3) The callbacks that would grab the values from the Message if the ws.secuiryt.* keys are insufficient. Dan > > Thanks > Oli > > ________________________________________ > Von: Daniel Kulp [dk...@apache.org] > Gesendet: Freitag, 3. Juni 2011 17:07 > An: users@cxf.apache.org > Cc: Oliver Wulff; cohei...@apache.org > Betreff: Re: AW: Secured java web application calls secured web services > with identity delegation > > 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/a > > pa > > che/cxf/ws/security/trust/delegation/WSSUsernameCallbackHandler.java?vie > > w=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 -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
