WS-Security client: dynamic UsernameToken

[wdarby]

I am trying to integrate RiftSaw with a WS-Security service that uses a UsernameToken. The challenge is that I need to specify the username and password based on received messages, rather than a static configuration. As I read the examples and user documentation for configuring WS-Security (for both ODE and RiftSaw), they are based on static configuration. I believe I understand the calls required on the CXF side, but I don't see how to hook into that layer from the BPEL runtime. Is this possible? Do you have any pointers for more information?

Thanks for the help

- Will Darby

[jeffdelong]

Riftsaw 2.2.0.CR1 has an example, bpel_helloworld_saml (in the samples/esb folder that shows how to copy a WS-Security element from one part of the message to another. In this example it uses the ESB to request a SAML token from PicketLink STS, using a Username token sent by the client. Perhaps but a similar approach may work for you (though not knowing your specific requirement it is hard to say for sure).

[wdarby]

Thanks, that was very fruitful. I have a related question on BPEL style, if you'll indulge me.

In the case above I am emulating a legacy web service that provides a login operation (with username and password), then accepts numerous other requests (perhaps for hours) until a logout or timeout occurs, where the session is coordinated with a token parameter. Since I'm using WS-Security with UsernameToken on the backend I need to retain the username/password to send with each request.

It appears that the straightforward way to implement this is to construct a long-running BPEL process using the token as a correlation id. Then I can just keep the username in a process variable, and use it with each backend request.

My question is if this is a reasonable approach with BPEL, and what is referred to as a long-running process execution, or if there is a better way to associate additional variables with a correlation.

Thanks again for your assistance

- Will

[jeffdelong]

This approach seems to imply that any requests by the same user (i.e. with the same UsernameToken), are for the same BPEL process instance. Assuming this is true I don't see why this would not make a good correlation property.

What is perhaps more interesting is whether BPEL is the appropriate way to implement this Web service. Is there some repeatable set of requests that can be composed by a well-defined set of services that are invoked based on each request?

[wdarby]

Thanks for the response. That is the behavior I'm looking for.

The reason I chose BPEL for this service was twofold:

1 - I am bridging two services a) the legacy service that I am replacing and the new backend service. A single operation may operate on both.

2 - To establish a BPEL beachhead for more advanced process coordination down the road.

Regards

- Will

[jeffdelong]

Sounds reasonable. Check out JBoss ESB as well. Like the example I pointed you at, I find the combination of the two more powerful than either by itself.