Thanks, thought so. Why does MS make it so hard to do the obvious simple
things while constructing great edifices to do obscure complicated things?
Come on MS - why not do something to make life easier for us developers?
I guess a solution might be for me to use SSL (or X.509 in WSE) to transmit
username and password to the server where it can be stored, then use plain
HTTP after that. The pain is that I presumably have to do some code at the
top of every method to impersonate that user, as well as sending some hash
to prove client identity - all very painful. Is there some way to use WSE
to hide this sort of stuff away under the hood? Ideally it should just
happen transparently, or perhaps need no more than an [Impersonate]
attribute on a class or method!
SSL processor cards are not much good, as I can't assume that every user
will want to buy one. Judging by the speed of Amazon's secure site at the
weekend (presumably they have these) even such addons aren't enough to make
SSL usable. Why oh why can't someone do the obvious and come up with
"SSL++", a protocol which uses asymmetric encryption to swap a secret key,
then use this key to encrypt/decrypt subsequent traffic symmetrically much
faster, all under the hood? It would really make web services practical at
last! Come on Microsoft - this is a fantastic addon for WSE 3.0, Indigo
and/or IIS. Revolutionise the Internet and save the world...
It's just so frustrating - all this security stuff, but the simplest, most
obvious thigs have slipped through the net!
Cheers,
Tim
"Dominick Baier" <dotnet@leastprivilege.com> wrote in message
news:eyhg%23dVmEHA.412@TK2MSFTNGP10.phx.gbl...[color=blue]
> Hi,
>
> you are right - Windows needs the password in plaintext to impersonate a[/color]
user (having to call LogonUser, which requires a password). Thinking about
it - it is the only way Windows can do it.[color=blue]
>
> So if you want to use the Windows infrastructure that's already there you[/color]
have to combine option 1 or 3 with option 2. If SSL seems too slow to you -
buy a SSL processor card (IIS6 supports them) to speed up the encryption.[color=blue]
>
> Another option would be (works only on IIS 6 being a domain member) -
>
> you can leverage the new W2K3 Kerberos S4U services.
>
> 1) use wse the send hashed password
>
> 2) authenticate the user somehow and provide the cleartext password in[/color]
UserNameTokenManager[color=blue]
>
> or
>
> 1) use a X509 Token
>
> 2) authenticate the token somehow
>
> associate the user with a existing windows account (e.g. through a[/color]
database) and call[color=blue]
>
> WindowsIdentity winid = new WindowsIdentity("user@domain");
>
> WindowsPrincipal principal = new WindowsPrincipal(winid);
>
>
>
> you will get a token that you can use for role inspection (calling[/color]
IsInRole).[color=blue]
>
> To impersonate to access local resources the service has to run as LOCAL[/color]
SYSTEM[color=blue]
>
> To impersonate to access remote resources, configure constrained[/color]
delegation in AD for the WebServer (you don't have to be running under
SYSTEM in this case)[color=blue]
>
> to enable both scenarios, just call winid.Impersonate();
>
>
>
> hope this helps
>
>
>
> ---
> Dominick Baier - DevelopMentor
>
http://www.leastprivilege.com
>
>
>
>
>
>[/color]
nntp://news.microsoft.com/microsoft.public.dotnet.framework.webservices/<#vcuM9RmEHA.2764@TK2MSFTNGP11.phx.gbl>[color=blue]
>
> Hello all,
>
> I'm trying to do something which I believe is very normal, standard sort[/color]
of[color=blue]
> requirement. I want to secure access to a web service across the Internet
> using username/password on the server, then impersonate the account on[/color]
that[color=blue]
> 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,[/color]
but[color=blue]
> runs ridiculously slowly because asymmetric encryption is so ludicrously
> slow and a complete waste as there's no need to encrypt much apart from[/color]
the[color=blue]
> 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[/color]
be[color=blue]
> some chat about using hashed passwords, which would be absolutely ideal,[/color]
but[color=blue]
> 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
>
>
>
>
>
>
>
>
>
> [microsoft.public.dotnet.framework.webservices][/color]
