You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Glen Mazza <gl...@gmail.com> on 2009/09/23 17:44:23 UTC
Re: WCF Service not accepting UsernameToken in security header
along with SecurityContextToken sent by CXF client
Dan, tough issue here, but wouldn't you say that SOAP clients programmed to
use the WSS4JOutInterceptor for UsernameToken security should ideally
continue to work even if the web service provider's security requirements
are defined using WS-SecurityPolicy? (I.e., the client code should not have
to change)? For example, let's say I have a CXF client configured using the
traditional WSS4JIn/OutInterceptor method[1] calling a CXF-based web
service, but then I switch to a Metro web service requiring the same UT
security but instead with it configured via WS-SecPol. I would guess the
CXF client should still be able to work without code changes--after all, the
client is still sending the security header, even if coded using
WSS4JOutInterceptor.
Stated another way, what is the purpose of WS-SecurityPolicy from a SOAP
client perspective--is it just to specify the security requirements a client
has to fulfill for the SOAP call to work, or does it imply that the web
service stack should automatically create the SOAP header (with additional
user-supplied parameters) for the web service call? If the former, a SOAP
client should probably still work if WSS4J is manually used; if the latter,
then manual usage of WSS4J to create another SOAP header (above and beyond
the header created by the CXF WS-SecPol implementation) should perhaps raise
an error somehow.
Thanks,
Glen
[1] http://www.jroller.com/gmazza/entry/using_cxf_and_wss4j_to
Thanks for setting up the test endpoint. Definitely helped. I can now
invoke on that endpoint fine.
These should now be fixed on trunk. Tonights snapshots should have them.
I
need you to double check your setup though. From the information you sent,
it LOOKS like you are kind of combinding the WS-SecurityPolicy stuff with
the
older WSS4JOutInterceptor. I THINK that's where the second UsernameToken
is
coming from. If using WS-SecurityPolicy, there is no-need to configure any
of the WSS4J stuff. The policy runtime does that for you according to the
policy. All you need to do is provide the extra information. In your
case,
all you need is the information of the UsernameToken for obtaining the
SecureConversationToken. Thus, you just need:
((BindingProvider)port).getRequestContext()
.put("ws-security.username.sct", "username");
((BindingProvider)port).getRequestContext()
.put("ws-security.password.sct", "password");
or use:
"ws-security.callback-handler.sct", new MyPasswordHandler(...)
to provide the callback instead of passing the password directly.
Please let me know if that works out ok so I can close off CXF-2158.
Thanks!
Dan
On Mon April 6 2009 1:36:13 pm Daniel Kulp wrote:
> Ok.... thanks for reporting these. The TransportBinding stuff in
> relation to WS-SecConv is definitely the least tested as the "live" https
> endpoints at MS interop plugfest site have not been working for a couple
> months now. :-(
>
> So, I see three issues that you've reported:
> 1) The UsernameToken being sent along with the SecCont token. According
> to the policies, the UsernameToken should just be sent to obtain the
> SecCont token. Once that is obtained, it shouldn't be sent. Not sure
> why
> it is yet.
>
>
> 2) Using the wrong Id to reference the SecCont token. The fix here is to
> use:
> sig.setKeyIdentifierType(WSConstants.CUSTOM_SYMM_SIGNING_DIRECT);
> instead of:
> sig.setKeyIdentifierType(WSConstants.CUSTOM_SYMM_SIGNING);
> OR use:
> sig.setCustomTokenId(secTok.getWsuId());
> I'll get that fixed in the code. That was updated in the Asym and Sym
> binding handlers when testing/implementing the WS-SecConv stuff. (it
> required some fixes to WSS4J as well) As mentioned above, the https
> endpoint as MS isn't working so we didn't catch that change in the
> transport binding. :-(
>
>
> 3) Some validation thing that something should be signed.... I still
> need
> to look at that more...
>
> BTW: is there any way you could put this on a "live" site temporarily? I
> don't have any Windows boxes and my .NET folks are busy for the next
> couple
> days. I'll try and get something similar setup in the cxf test suites
> using a cxf endpoint, but if I could hit a live site for testing, that
> would be great.
>
> Dan
>
--
View this message in context: http://www.nabble.com/WCF-Service-not-accepting-UsernameToken-in-security-header-along-with-SecurityContextToken-sent-by-CXF-client-tp22912335p25531202.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WCF Service not accepting UsernameToken in security header
along with SecurityContextToken sent by CXF client
Posted by Glen Mazza <gl...@gmail.com>.
dkulp wrote:
>
>> Stated another way, what is the purpose of WS-SecurityPolicy from a SOAP
>> client perspective--is it just to specify the security requirements a
>> client has to fulfill for the SOAP call to work, or does it imply that
>> the
>> web service stack should automatically create the SOAP header (with
>> additional user-supplied parameters) for the web service call? If the
>> former, a SOAP client should probably still work if WSS4J is manually
>> used; if the latter, then manual usage of WSS4J to create another SOAP
>> header (above and beyond the header created by the CXF WS-SecPol
>> implementation) should perhaps raise an error somehow.
>
> For CXF, it's definitely the latter. The policies in the wsdl are used
> to
> control the runtime. The policies select which interceptors and features
> to
> activate which then manipulate how the message is constructed.
> Currently,
> there isn't any interaction between the older interceptors (that the user
> would have added) and the newer interceptors (that the policy engine would
> add). There probably could be, but there currently isn't. A simple
> option could be to add a simple flag in WSS4J*Interceptor that said
> "wssec-
> done" = true or something and if that flag is set in the PolicyWSSJ4*
> stuff,
> they would just assert all the wss policies and return immediately. Not
> ideal, but simple. The other next step up would be to add some policy
> aware
> stuff to WSS4J* which would examine the configuration and try and figure
> out
> which policies to assert. If they are already asserted in PolicyWSS4J*
> stuff, just skip those sections. Not exactly sure how doable that is as
> I'm
> not sure how well the wss4j config would map onto the policies. The
> OTHER
> option (probably better option) is to update the WSS4J* interceptors to
> detect
> if the Policy aware versions are there and then just convert their config
> into
> properties that the policy aware versions would require. Set the ws-
> security-* flags on the message so the PolicyAware versions can pick them
> up.
>
> Definitely a bunch of options, just none of it is implemented that way.
> The
> only real option right now is to turn off the policy engine (see the 2.2
> migration guide) or migrate your configuration.
>
> Dan
>
I see. I think the status quo--migrate config or deactivate policy
engine--isn't that bad anyway. Thanks for the information.
Glen
--
View this message in context: http://www.nabble.com/WCF-Service-not-accepting-UsernameToken-in-security-header-along-with-SecurityContextToken-sent-by-CXF-client-tp22912335p25604979.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WCF Service not accepting UsernameToken in security header along with SecurityContextToken sent by CXF client
Posted by Daniel Kulp <dk...@apache.org>.
On Wed September 23 2009 11:44:23 am Glen Mazza wrote:
> Dan, tough issue here, but wouldn't you say that SOAP clients programmed to
> use the WSS4JOutInterceptor for UsernameToken security should ideally
> continue to work even if the web service provider's security requirements
> are defined using WS-SecurityPolicy? (I.e., the client code should not
> have to change)?
Hmm... well... no. At least it currently wouldn't work. The older
WSS4JOutInterceptor is not policy aware at all and there really isn't a way
for the newer policy aware interceptors to know what the WSS4JOutInterceptor
has already done.
Lets use your UsernameToken case as an example. For a
TransportBinding/UsernameToken, the policy based out interceptor could easily
look into the message to see if a UsernameToken is there and just assert the
policy and continue. Not a big deal. However, lets assume a SymetricBinding
with an encrypted UsernameToken. The policy based out interceptor really
couldn't look into the message to see what's there. It would be encrypted.
Thus, we would need to update the WSS4J*Interceptors to start recording more
about what they did so the policy aware versions could skip themselves or
similar.
> For example, let's say I have a CXF client configured
> using the traditional WSS4JIn/OutInterceptor method[1] calling a CXF-based
> web service, but then I switch to a Metro web service requiring the same
> UT security but instead with it configured via WS-SecPol. I would guess
> the CXF client should still be able to work without code changes--after
> all, the client is still sending the security header, even if coded using
> WSS4JOutInterceptor.
>
> Stated another way, what is the purpose of WS-SecurityPolicy from a SOAP
> client perspective--is it just to specify the security requirements a
> client has to fulfill for the SOAP call to work, or does it imply that the
> web service stack should automatically create the SOAP header (with
> additional user-supplied parameters) for the web service call? If the
> former, a SOAP client should probably still work if WSS4J is manually
> used; if the latter, then manual usage of WSS4J to create another SOAP
> header (above and beyond the header created by the CXF WS-SecPol
> implementation) should perhaps raise an error somehow.
For CXF, it's definitely the latter. The policies in the wsdl are used to
control the runtime. The policies select which interceptors and features to
activate which then manipulate how the message is constructed. Currently,
there isn't any interaction between the older interceptors (that the user
would have added) and the newer interceptors (that the policy engine would
add). There probably could be, but there currently isn't. A simple
option could be to add a simple flag in WSS4J*Interceptor that said "wssec-
done" = true or something and if that flag is set in the PolicyWSSJ4* stuff,
they would just assert all the wss policies and return immediately. Not
ideal, but simple. The other next step up would be to add some policy aware
stuff to WSS4J* which would examine the configuration and try and figure out
which policies to assert. If they are already asserted in PolicyWSS4J*
stuff, just skip those sections. Not exactly sure how doable that is as I'm
not sure how well the wss4j config would map onto the policies. The OTHER
option (probably better option) is to update the WSS4J* interceptors to detect
if the Policy aware versions are there and then just convert their config into
properties that the policy aware versions would require. Set the ws-
security-* flags on the message so the PolicyAware versions can pick them up.
Definitely a bunch of options, just none of it is implemented that way. The
only real option right now is to turn off the policy engine (see the 2.2
migration guide) or migrate your configuration.
Dan
>
> Thanks,
> Glen
>
> [1] http://www.jroller.com/gmazza/entry/using_cxf_and_wss4j_to
>
>
>
> Thanks for setting up the test endpoint. Definitely helped. I can now
> invoke on that endpoint fine.
>
> These should now be fixed on trunk. Tonights snapshots should have them.
> I
> need you to double check your setup though. From the information you
> sent, it LOOKS like you are kind of combinding the WS-SecurityPolicy stuff
> with the
> older WSS4JOutInterceptor. I THINK that's where the second UsernameToken
> is
> coming from. If using WS-SecurityPolicy, there is no-need to configure
> any of the WSS4J stuff. The policy runtime does that for you according
> to the policy. All you need to do is provide the extra information. In
> your case,
> all you need is the information of the UsernameToken for obtaining the
> SecureConversationToken. Thus, you just need:
>
>
> ((BindingProvider)port).getRequestContext()
> .put("ws-security.username.sct", "username");
> ((BindingProvider)port).getRequestContext()
> .put("ws-security.password.sct", "password");
>
> or use:
> "ws-security.callback-handler.sct", new MyPasswordHandler(...)
> to provide the callback instead of passing the password directly.
>
> Please let me know if that works out ok so I can close off CXF-2158.
>
> Thanks!
> Dan
>
> On Mon April 6 2009 1:36:13 pm Daniel Kulp wrote:
> > Ok.... thanks for reporting these. The TransportBinding stuff in
> > relation to WS-SecConv is definitely the least tested as the "live" https
> > endpoints at MS interop plugfest site have not been working for a couple
> > months now. :-(
> >
> > So, I see three issues that you've reported:
> > 1) The UsernameToken being sent along with the SecCont token. According
> > to the policies, the UsernameToken should just be sent to obtain the
> > SecCont token. Once that is obtained, it shouldn't be sent. Not sure
> > why
> > it is yet.
> >
> >
> > 2) Using the wrong Id to reference the SecCont token. The fix here is
> > to use:
> > sig.setKeyIdentifierType(WSConstants.CUSTOM_SYMM_SIGNING_DIRECT);
> > instead of:
> > sig.setKeyIdentifierType(WSConstants.CUSTOM_SYMM_SIGNING);
> > OR use:
> > sig.setCustomTokenId(secTok.getWsuId());
> > I'll get that fixed in the code. That was updated in the Asym and Sym
> > binding handlers when testing/implementing the WS-SecConv stuff. (it
> > required some fixes to WSS4J as well) As mentioned above, the https
> > endpoint as MS isn't working so we didn't catch that change in the
> > transport binding. :-(
> >
> >
> > 3) Some validation thing that something should be signed.... I still
> > need
> > to look at that more...
> >
> > BTW: is there any way you could put this on a "live" site temporarily?
> > I don't have any Windows boxes and my .NET folks are busy for the next
> > couple
> > days. I'll try and get something similar setup in the cxf test suites
> > using a cxf endpoint, but if I could hit a live site for testing, that
> > would be great.
> >
> > Dan
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog