Re: UserNameToken with SendNone on Password

From: SA (informatica_at_freemail.nl)
Date: 02/15/05 

Date: Tue, 15 Feb 2005 11:31:43 -0600

James,

let's see if we can address some of your concerns.

> Anyhow, I like your solution better, but I'm getting confused and
> frustrated. GETSCTNew aparently needs a class that is inherited from
> SoapClient. Well of course this isn't a soap communication beyond the
fact
> that it's a web service so it's using soap stuff under neath. At that
point
> I get confused, becuase how the heck do I send this stuff?

It depends. On the client side, the service proxy inherits from SoapClient.
On the server-side, the service interface inherits from SoapService.

I don't see why you are saying that's not SOAP communication... It
definitely is sending SOAP messages back and forth. I implement all my web
services that way. I need to write my own proxies rather than relying on
wsewsdl2.exe (or whatever that tool is called...), but it gives me much more
control for very little effort.

Please try the sample I supplied. Let me/us know if you have any questions
about it, after walking through it with the debugger.

> Right now I do this:

<snip>

> Which signs and encrypts the communication nicely.
>
> us = a web service that is in my web references.

Actually, "us" is just a class that's auto-generated by the WSDL tool. It is
not a web service, it's a web service proxy.

So basically, you'd write your own "us" class. That will be a class that
inherits from SoapClient. That class' interface will resemble your server
class' interface (just like "us" does now).

> On the server side I have it setup in my web.config so that it knows about
> my implimentation of usernametoken and I do my own authentication in that
> class and then every web method I then check the soap contents to make
sure
> that it is encrypted, signed and has a valid usernametoken on it.

OK, so you basically have a custom UsernameTokenManager. You won't need that
any longer with this implementation. Much has been written about that
lately, but the conclusion is always that unless you use SSL every time, all
the time, there is no secure way to use UsernameTokens.

> Add to that a ton of functions that I can't find that you use all over the
> place and I'm really lost. (hence why I asked how to use SendNone on
> UserNameTokens so that I could do this the easy way)

OK, walk through the sample with a debugger. Take the encryption and hashing
stuff for granted. (That's black box stuff, it really has nothing to do with
this sample...) The only thing you need to understand is where a
public/private key pair is used and where a shared session key is used. If
you see RSA encryption, then it's PKI. If you see Rijndael, then that refers
to the shared session key.

If there are any non-encryption related functions you can't seem to find,
check the WSE documentation first. More than likely, there inherited from
SoapClient or SoapService, or static (Shared) methods of WSE 2.0 classes. If
you still don't seem to find the function, let me/us know.

Also review the architecture document that's included. If you don't have a
means to open Visio files (there's a free viewer available from Microsoft at
[1], but I understand if you don't want to install that), I will create a
PDF from that file. Print it, and annotate is you like when going through
the sample.

> Man I hope they make this stuff easier in Indigo... I thought Avalon was
> going to be great, but now I am convinced that Indigo is going to be where
> it's at if they finally fix this and make encryption without certificates
> easy.

Unfortunately, security is never "easy." If it was, people wouldn't need us
anymore, they could just drag-and-drop their way to interoperable web
services. Pray that day never comes, or that you have another job offer by
that time ;o)

Just exaggerating. But the main point still is that using usernames and
passwords is increasingly risky because of several reasons, some of which
are outlined in Keith's article at [2].

[1] http://office.microsoft.com/en-us/officeupdate/CD010798711033.aspx

[2]
http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnwse/html/securusernametoken.asp