You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Oliver Wulff <ow...@talend.com> on 2011/06/03 11:58:54 UTC
Secured java web application calls secured web services with
identity delegation
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
AW: AW: AW: Secured java web application calls secured web services
with identity delegation
Posted by Oliver Wulff <ow...@talend.com>.
>>>
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 [dkulp@apache.org]
Gesendet: Dienstag, 7. Juni 2011 21:35
An: users@cxf.apache.org
Cc: Oliver Wulff; coheigea@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 [dkulp@apache.org]
> Gesendet: Freitag, 3. Juni 2011 17:07
> An: users@cxf.apache.org
> Cc: Oliver Wulff; coheigea@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 [coheigea@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 <ow...@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
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: AW: AW: Secured java web application calls secured web services with identity delegation
Posted by Daniel Kulp <dk...@apache.org>.
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 [dkulp@apache.org]
> Gesendet: Freitag, 3. Juni 2011 17:07
> An: users@cxf.apache.org
> Cc: Oliver Wulff; coheigea@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 [coheigea@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 <ow...@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
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
AW: AW: Secured java web application calls secured web services
with identity delegation
Posted by Oliver Wulff <ow...@talend.com>.
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.
An option would be that we provide as part of CXF such kind of callback which reads the token from the TLS.
Thanks
Oli
________________________________________
Von: Daniel Kulp [dkulp@apache.org]
Gesendet: Freitag, 3. Juni 2011 17:07
An: users@cxf.apache.org
Cc: Oliver Wulff; coheigea@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 [coheigea@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 <ow...@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
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: AW: Secured java web application calls secured web services with identity delegation
Posted by Daniel Kulp <dk...@apache.org>.
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 [coheigea@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 <ow...@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
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
AW: Secured java web application calls secured web services with
identity delegation
Posted by Oliver Wulff <ow...@talend.com>.
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 [coheigea@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/apache/cxf/ws/security/trust/delegation/WSSUsernameCallbackHandler.java?view=markup
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 <ow...@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
Re: Secured java web application calls secured web services with
identity delegation
Posted by Colm O hEigeartaigh <co...@apache.org>.
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/apache/cxf/ws/security/trust/delegation/WSSUsernameCallbackHandler.java?view=markup
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 <ow...@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