I am using WSE3 with usernametoken authentication and for some reason on the
server a call to
RequestSoapContext.Current.Credentials.UltimateReceiver.GetClientToken<UsernameToken>() returns null.
Now, I know the username token is being sent by the client and received by
the web service for 2 reasons:
1) If the username token is created using an invalid username/password
combo, then I get a SecurityFault exception.
2) I have turned on diagnostics at both ends and inspected the soap messages
and the username token is in there ok.
I reckon I must be doing something really silly, but I can't think of
anything. As I say, I *know* the username token is being received by the web
service (so my configuration files must be set up correctly, right?) and yet
the call to get the token returns null and I just can't figure it out.
I am not using certifcates or any other form of authenticating/encryption,
just the usernameOverTransportSecurity turnkey (with default
UsernameTokenManager, as I'm authenticating against AD, and like I say it
authenticates successfully). I have other web services where everything works
fine, and I'm scratching my head as I can't see how they're any different.
Any help/ideas would be greatly appreciated.
Thanks
Mark
Pablo Cibraro [MVP] - 25 Oct 2006 19:03 GMT
Hi Mark,
If you are using SecureConversation, the client token is a SCT and not a
UsernameToken, maybe it is returning null for that reason.
Try with this property,
Microsoft.Web.Services3.RequestSoapContext.Current.IdentityToken
It's the right property to get the authenticated token.
Regards,
Pablo Cibraro.
>I am using WSE3 with usernametoken authentication and for some reason on
>the
[quoted text clipped - 29 lines]
>
> Mark
Zoodor - 26 Oct 2006 11:51 GMT
Thankyou for your reply Pablo,
I am not using SecureConversation and
Microsoft.Web.Services3.RequestSoapContext.Current.IdentityToken is null.
However, i have finally managed to track down the problem - I hadn't set the
policy attribute on my web service. As I said originally, a silly thing that
I should have spotted, though I am confused as to why it was doing
authentication at all if the policy was not set to use it...?