Why I spent a Sunday afternoon trying to get SecureConversation to work

By process of (hours of) elimination I have solved a problem that was driving me batty today!

I have a WSE 3.0 enabled client app that calls a WSE enabled web service.

After creating a UsernameToken, the client application was setting the credentials on the web service proxy using the generic overload:

proxy.SetClientCredential(Of UsernameToken) (myUT)

As I built the tests up one by one everything was working swimmingly… until I added in the SecureConversation into the client and service policies. (establishSecurityContext=”true”).

Then I was getting a 401 Access denied whenever I tried to hit the web service. I could see through the status of the tracing that I was not even touching the web server on these calls.

Setting the SecureConversation to false let everything work again.

I spent quite a lot of time experimenting and scrutinizing my settings, configs, etc.

I even loaded up the sample application for Secure Conversation which worked perfectly fine.

Both web services were in IIS and I compared everything. config files, policy files, IIS properties and security, folder security.

Combing through these, I tested every little thing that was different – folder access permissions and more. I explored differences in code such as setting the soapversion explicitly on the proxy. Nothing made a difference.

But finally, I came upon the nominal difference that was causing the problem (though I have no explanation for it).

It was the use of generics in setting the ClientCredential on the proxy.

When I used the non-generic method, as the sample uses:

proxy.SetClientCredential(myUT)

instead of

proxy.SetClientCredential(Of UsernameToken) (myUT)

suddenly I was getting a response from the server. It was still an error, but I knew I was finally getting through to the server.

The new error was my method of doing authorization on the token. This new token was “just a securityContextToken” and not a UsernameToken.

In my web service, I had cobbled together some old WSE 2.0 authorization code with some WSE 3.0 code which looked like this

dim tok as UsernameToken=RequestSoapContext.Current.IdentityToken

if tok.Principal.IsInRole(….blah blah blah

When attaching the credentials using the generic method, IdentityToken was returned as a UsernameToken, but now it is not. It has a base of UsernameToken, but it doesn’t cast (I tried) to UsernameToken.

I can get the principal directly from IdentityToken anyway, so I just modified that code

dim tok as SecurityToken = RequestSoapContext.Current.IdentityToken
if tok.Principal.IsInRole(….blah blah blah

This cost me many many hours. At least now there will be something for Google to find!!

Don’t Forget: www.acehaid.org

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!  

One thought on “Why I spent a Sunday afternoon trying to get SecureConversation to work

Leave a Reply to Why I spent a Sunday afternoon trying to get SecureConversation to work Cancel reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.