Hi Karl

On Fri, Feb 25, 2011 at 4:38 PM, Rhenius, Karl Stefan <[email protected]> wrote:
> Hi Sergey
>
>> thanks for the clarifications and your patience :-)
> You are all making a great job with cxf, being patient or building a
> testcase is the minimum I can do for you!
>
>> Would it make sense to have two ports for a single service or two
>> services, one supporting a SecCon only and the other supporting plain
>> UTs only ?
>
> That doesn't sound as cool as policy alternatives.
> Do you mean something like:
> <wsdl:service>
>  <wsdl:port name="Foo" binding="UtBinding" />
>  <wsdl:port name="FooSec" binding="SecConvBinding" />
> </wsdl:service>
>
> Is this a valid configuration? I'll test it on Monday, but I'd prefer
> policy alternatives.

It is a valid configuration, but you may want to have a single binding
and push the policies to the individual ports :

<wsdl:service>
  <wsdl:port name="FooUT" binding="HelloWorldBinding" >
     <UT/>
  </wsdl:port>
  <wsdl:port name="FooSec" binding="HelloWorldBinding" >
     <SecureConversation/>
  </wsdl:port>
</wsdl:service>


Policy alternatives are fine, and if it makes sense to have them
available in the context of a single port/endpoint then sure, why not,
but spreading them across ports/services may also be an option, it
really depends on the actual case...

>
> Even if the mix of encrypted messages and plain text isn't common, there
> are other scenarios, where the outgoing message format relates to the
> incoming.
> Let's assume you'd like to offer two SecureConversation policies with
> different encryption algorithms or key strength - cxf shouldn't roll a
> dice to chose an output format :)
>
>> This is what I meant, it could be tricky, though feasible, to figure
>> out dynamically which alternative has to be satisfied
>
> I think cxf should remember which policy was valid for the incoming
> message and use it for the outgoing message. This seems to involve no
> guesswork on the outgoing side. But that's just an idea without knowing
> anything about the code.

That is the tricky bit. Even a single Ws-Sec policy may have many
nested policies.
May be CXF can add its own custom SOAP header to the response, which,
assuming the CXF client is on the other side will be returned.
Or may be it should iterate over all the alternatives and then have
PolicyAlternative return a matching score, say UT-only policy will
return 1, SecureConversation policy will return 2, given that it will
recognize the SecCon header and the UT. But this is just a theory :-)

Cheers, Sergey

>
> Cheers
> Karl
>

Reply via email to