You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Mayank Mishra <ma...@gmail.com> on 2008/12/09 12:03:02 UTC
JAX-WS request-response
Hi,
I am working on WS-Trust support for CXF. The requirement is like, while
creating a secured request from client to service, client requires to
communicate with STS to get required token. Depending on the security
requirements of the STS service specified in the wsdl and ws-trust spec, a
client may require to secure the STS communication.
Now, I am already in a requesting phase (client-server), how can I create
another nested request-response (client-STS and STS-client). Currently, I am
relying on the jax-ws Dispatch api to achieve this. I will use the wss4j api
to do the required security processing. Having a bootstrap communication
between client-sts is not a solution for this, right? Or Can I use reentrant
property of PhaseInterceptorChain to achieve this, I am not sure about this
option.
Does above sounds sensible? Any pointers/suggestions on how to achieve the
same by some better way will be appreciated.
With Regards,
Mayank
Re: JAX-WS request-response
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 10 December 2008 1:35:06 am Mayank Mishra
>
> What I did was, I had client and server side SecurityPolicy In and Out
> Interceptors which processes the wsdl, transforms SecurityPolicy specified
> in wsdl to respective Wss4J config (for Assymetric, Symmetric bindings).
> Then I had WS-TrustInterceptor which plugs-in, dispatch-client for RST and
> RSTR. I will change it to use endpoint.Client.invoke() (as per your
> sugession). Also, I was thinking to have configurable (Entropy, Lifetime,
> supported RequestedTokenType etc) STSImpl as ws-provider<Source> to have
> Issue, Validate, Renew and Cancel operations being supported. So that CXF
> Server to other client Interop can also be done. I can see Issue-RST right
> now in the cxf-trunk code.
>
> It's getting very parallel, I guess I must take Trunk's SecurityPolicy and
> Trust and build over it. Then I shall submit a patch to you in regard to
> same.
That would be great. I didn't get a chance to touch anything today. :-(
Seriously, the best bet is to open a JIRA (assign to me) and just start
attaching patches. Small patches each day is perfectly fine and probably
preferred so we both don't keep doing the same things.
Do it long enough and annoy me enough and we'll make you a committer. :-)
The SecurityPolicy stuff is working fairly well on the sending side. The
receiving side is kind of a joke right now. We just use the
wss4jInInterceptor and turn off all the validation. I need to actually
write a new InInterceptor that will really validate with the policies.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: JAX-WS request-response
Posted by Mayank Mishra <ma...@gmail.com>.
On Wed, Dec 10, 2008 at 9:02 AM, Daniel Kulp <dk...@apache.org> wrote:
> On Tuesday 09 December 2008 6:03:02 am Mayank Mishra wrote:
> > Hi,
> >
> > I am working on WS-Trust support for CXF. The requirement is like, while
> > creating a secured request from client to service, client requires to
> > communicate with STS to get required token. Depending on the security
> > requirements of the STS service specified in the wsdl and ws-trust spec,
> a
> > client may require to secure the STS communication.
> >
> > Now, I am already in a requesting phase (client-server), how can I create
> > another nested request-response (client-STS and STS-client). Currently, I
> > am relying on the jax-ws Dispatch api to achieve this. I will use the
> wss4j
> > api to do the required security processing. Having a bootstrap
> > communication between client-sts is not a solution for this, right? Or
> Can
> > I use reentrant property of PhaseInterceptorChain to achieve this, I am
> not
> > sure about this option.
> >
> > Does above sounds sensible? Any pointers/suggestions on how to achieve
> the
> > same by some better way will be appreciated.
>
> I've gone ahead and committed what I had started onto trunk.
>
> First off, the Dispatch API probably won't work for you right now. It
> needs
> some refactoring to get it to work with the standard Ws-Addressing and
> Security stuff which you may need for this. There is a JIRA for that
> someplace.
>
Yes, I can understand.
>
> What I committed uses some pretty low level API's to setup a Service. It
> COULD use a WS-Trust wsdl, but that would then require wsdl parsing and
> such
> which didn't seem worth it for just a couple operations.
>
> For the security stuff, it uses the new WS-SecurityPolicy stuff that is on
> the
> 2.2/trunk. Basically, if you have a policy to describe the requirements
> of
> the STS server, you just set it inot the STSClient and it should use it.
> (currently requires the policy stuff turned on on the Bus, will fix that
> shortly as it should be able to turn it on explicitely for itself)
>
What I did was, I had client and server side SecurityPolicy In and Out
Interceptors which processes the wsdl, transforms SecurityPolicy specified
in wsdl to respective Wss4J config (for Assymetric, Symmetric bindings).
Then I had WS-TrustInterceptor which plugs-in, dispatch-client for RST and
RSTR. I will change it to use endpoint.Client.invoke() (as per your
sugession). Also, I was thinking to have configurable (Entropy, Lifetime,
supported RequestedTokenType etc) STSImpl as ws-provider<Source> to have
Issue, Validate, Renew and Cancel operations being supported. So that CXF
Server to other client Interop can also be done. I can see Issue-RST right
now in the cxf-trunk code.
It's getting very parallel, I guess I must take Trunk's SecurityPolicy and
Trust and build over it. Then I shall submit a patch to you in regard to
same.
With Regards,
Mayank
>
> The start of the MS interopfest stuff for the trust10 stuff is at:
> http://svn.apache.org/repos/asf/cxf/sandbox/interopfest/wstrust10/
> I'm not getting a token back from their sts right now, but I think it's a
> problem on there end. It's getting this error back right now:
>
> The server was unable to process the request due to an internal error. For
> more information about the error, either turn on
> IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or
> from
> the <serviceDebug> configuration behavior) on the server in order to send
> the
> exception information back to the client, or turn on tracing as per the
> Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace
> logs.
>
> The Axis2/WSO2/Rampart clients are also getting an error back. Since I
> assume they worked at one point, I'll assume it's a problem on the MS side.
>
> Anyway, tomorrow I hope to start actually flushing out the
> requestSecurityToken method to actually create a proper response based on
> the
> trust policies.
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
Re: JAX-WS request-response
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 09 December 2008 6:03:02 am Mayank Mishra wrote:
> Hi,
>
> I am working on WS-Trust support for CXF. The requirement is like, while
> creating a secured request from client to service, client requires to
> communicate with STS to get required token. Depending on the security
> requirements of the STS service specified in the wsdl and ws-trust spec, a
> client may require to secure the STS communication.
>
> Now, I am already in a requesting phase (client-server), how can I create
> another nested request-response (client-STS and STS-client). Currently, I
> am relying on the jax-ws Dispatch api to achieve this. I will use the wss4j
> api to do the required security processing. Having a bootstrap
> communication between client-sts is not a solution for this, right? Or Can
> I use reentrant property of PhaseInterceptorChain to achieve this, I am not
> sure about this option.
>
> Does above sounds sensible? Any pointers/suggestions on how to achieve the
> same by some better way will be appreciated.
I've gone ahead and committed what I had started onto trunk.
First off, the Dispatch API probably won't work for you right now. It needs
some refactoring to get it to work with the standard Ws-Addressing and
Security stuff which you may need for this. There is a JIRA for that
someplace.
What I committed uses some pretty low level API's to setup a Service. It
COULD use a WS-Trust wsdl, but that would then require wsdl parsing and such
which didn't seem worth it for just a couple operations.
For the security stuff, it uses the new WS-SecurityPolicy stuff that is on the
2.2/trunk. Basically, if you have a policy to describe the requirements of
the STS server, you just set it inot the STSClient and it should use it.
(currently requires the policy stuff turned on on the Bus, will fix that
shortly as it should be able to turn it on explicitely for itself)
The start of the MS interopfest stuff for the trust10 stuff is at:
http://svn.apache.org/repos/asf/cxf/sandbox/interopfest/wstrust10/
I'm not getting a token back from their sts right now, but I think it's a
problem on there end. It's getting this error back right now:
The server was unable to process the request due to an internal error. For
more information about the error, either turn on
IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from
the <serviceDebug> configuration behavior) on the server in order to send the
exception information back to the client, or turn on tracing as per the
Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace
logs.
The Axis2/WSO2/Rampart clients are also getting an error back. Since I
assume they worked at one point, I'll assume it's a problem on the MS side.
Anyway, tomorrow I hope to start actually flushing out the
requestSecurityToken method to actually create a proper response based on the
trust policies.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog