Am I missing something or has MS missed the plot?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Tim Haynes - 13 Sep 2004 00:22 GMT

Hello all,

I'm trying to do something which I believe is very normal, standard sort of
requirement. I want to secure access to a web service across the Internet
using username/password on the server, then impersonate the account on that
server.

Option 1 - set IIS to basic authentication, which all works great, except
that passwords are transmitted in clear, so that's obviously useless.

Option 2 - as option 1, but encrypt everything using IIS. Seems great, but
runs ridiculously slowly because asymmetric encryption is so ludicrously
slow and a complete waste as there's no need to encrypt much apart from the
password.

On to option 3, WSE, but as far as I can tell from the confused
documentation, the only ways to impersonate are to use Kerberos (no use
here) or plain text passwords (just as bad as option 1). There seems to be
some chat about using hashed passwords, which would be absolutely ideal, but
I've yet to find and useful examples of a token manager which can do this
and just drop-in to an application?

It just seems that MS has really missed the plot here. Why has MS made
something so standard so difficult?

Any pointers, code, hints etc most welcome.

Cheers,

Tim
t_j_haynes@hotmail.com

Reply to this Message

Hervey Wilson [MSFT] - 22 Sep 2004 18:05 GMT

Comments inline.

Signature

This posting is provided "AS IS", with no warranties, and confers no rights.

> Hello all,
>
[quoted text clipped - 5 lines]
> Option 1 - set IIS to basic authentication, which all works great, except
> that passwords are transmitted in clear, so that's obviously useless.

Correct.

> Option 2 - as option 1, but encrypt everything using IIS. Seems great, but
> runs ridiculously slowly because asymmetric encryption is so ludicrously
> slow and a complete waste as there's no need to encrypt much apart from the
> password.

SSL does not use asymmetric encryption once the connection has been
established, it uses a generated symmetric key. A series of handshake
messages are used to authenticate the server and, optionally, the client and
to exchange this key. Thereafter all data on the connection is encrypted
with the symmetric key.

> On to option 3, WSE, but as far as I can tell from the confused
> documentation, the only ways to impersonate are to use Kerberos (no use
> here) or plain text passwords (just as bad as option 1). There seems to be
> some chat about using hashed passwords, which would be absolutely ideal, but
> I've yet to find and useful examples of a token manager which can do this
> and just drop-in to an application?

The WSE2.0 samples should illustrate how to send a plaintext password to a
service using the UsernameToken. This exchange must of course be protected:
either it occurs over an secure channel such as SSL or the client
application uses the servers certificate to encrypt the UsernameToken when
it is sent. This too should be illustrated in the WSE2.0 samples.

The UsernameToken.SendHashed option can be used to transmit values that are
derived from the password, however this option cannot be used if you wish to
authenticate the user against and AD service since WSE needs to use
LogonUser and that requires the plaintext password. It can be used against a
custom username/password database, see
http://www.dynamic-cast.com/mt-archives/000065.html for more details.

Within WSE, you can override the UsernameTokenManager and perform
impersonation if you require it for all your services within the app domain.
The default UsernameTokenManager takes the token and performs a LogonUser
(assuming a plaintext password was passed). It then sets the
UsernameToken.Principal property to be a Windows IPrincipal. You can use
this to either impersonate directly within the UsernameTokenManager for all
services, or in code on a per service / per method basis.

Note that WSE2 also supports WS-SecureConversation which allows you to
authenticate using a UsernameToken and thereafter use an opaque, generated
symmetric key for further message exchanges. The opaque token (a
SecurityContextToken) is available at the service and also has a Principal
property - this property reflects the value from the UsernameToken that was
used for the original authentication step.There are samples in the product
that illustrate the use of SecureConversation and it is covered in the
documentation.

> It just seems that MS has really missed the plot here. Why has MS made
> something so standard so difficult?

I don't think it's actually that difficult, but would agree that the
mechanism for WSE2 may not be very discoverable from the samples and
documentation.

> Any pointers, code, hints etc most welcome.
>
> Cheers,
>
> Tim
> t_j_haynes@hotmail.com

Reply to this Message

Am I missing something or has MS missed the plot?

Free Magazines