Cheers (very fast response) ... I'll take a look at the snapshot
tomorrow.
Yep - that security configuration works for me. I added a comment to http://cwiki.apache.org/CXF20DOC/ws-securitypolicy.html
describing this API usage.
Thanks,
Ian
On 6 Apr 2009, at 21:32, Daniel Kulp wrote:
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
On Mon April 6 2009 12:23:57 pm Ian Homer wrote:
Hi,
We were connecting a CXF client to WCF as described in tutorial "WCF
Getting Started Sample Tutorial with Message Security User Name" @
http://msdn.microsoft.com/en-us/library/ms752233.aspx and as
reported in
a JIRA ticket (for another issue) @
https://issues.apache.org/jira/browse/CXF-2158
We found that WCF was throwing the following exception ...
Cannot find a token authenticator for the
'System.IdentityModel.Tokens.UserNameSecurityToken' token type.
Tokens of that type cannot be accepted according to current
security settings.
which we traced to being related to the WCF Service not accepting
UsernameToken in security header along with SecurityContextToken
sent
by CXF client. CXF was sending both, i.e.
<c:SecurityContextToken xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc
"
xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecur
it y-utility-1.0.xsd "
u:Id="uuid-b7c16c8a-9816-4422-ac82-39ebbc64ae9e00">
<c:Identifier>urn:uuid:1bfddc0c-944d-4c6b-99f9-9a1aa49f5700</
c:Identifier>
</c:SecurityContextToken>
<wsse:UsernameToken
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsse
cu rity-secext-1.0.xsd "
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssec
ur ity-utility-1.0.xsd "
wsu:Id="UsernameToken-253884022">
<wsse:Username>BART\myname</wsse:Username>
<wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-
to ken-profile-1.0#PasswordText ">password</wsse:Password>
</wsse:UsernameToken>
Is there a way to configure the CXF client to only include the
UsernameToken once?
The work around we applied was to create the following extension to
the WSS4JOutInterceptor
public class JustOnceWSS4JOutInterceptor extends
WSS4JOutInterceptor {
int count = 0;
/**
* @param outProps
*/
public JustOnceWSS4JOutInterceptor(Map<String, Object> outProps) {
super(outProps);
}
@Override
public void handleMessage(SoapMessage mc) throws Fault {
if (count == 0) {
super.handleMessage(mc);
}
count++;
}
}
although I'm sure there's a better way of doing this.
Ian
--
Daniel Kulp
[email protected]
http://www.dankulp.com/blog
--
Ian Homer | http://blog.bemoko.com
