Hi Sidd,
Thanks for the quick response.
Rather than expanding on the current setup, which was designed with little
knowledge of WSE during the TP and is probably flawed, I'll describe our
scenario. It would be great to get direction from someone in-the-know.
Technology:
We're an ISV that sells a product consisting of two services (hosted on a
server) that can be hosted in Windows Services or IIS, as well as client
tools that talk to these services. The services are written as SoapServices
and we're registering them as HttpHandlers when hosted in IIS (we aren't
using ASMX). The clients use custom proxies that extend SoapClient.
Requirements:
Since the applications are bundled and sold as a single product, we can't
have requirements like certificate servers; anyone should be able to buy the
product and install it with minimal impact to OS configuration. Customers
can use our user database, AD, LDAP, or anything else they write a provider
for, so we must send the password over the wire. That's it, really. Simple
stuff.
What would be the simplest solution? I appreciate your input.
Thanks,
-jk
[quoted text, click to view] "Sidd" <ElCid@hotmail.com> wrote in message
news:40db721c$1@news.microsoft.com...
> Hi Jeff,
>
> In TechPreview, WSE did not cache any username tokens. In RTM, the
> behavior is that if you sign
> with a username, then it is automatically put in a cache, so that when a
> reply comes back encrypted with the same
> token, it can decrypt it.
>
> One side effect of caching is the behavior your are seeing below. When
> a
> request comes in, the cache is first
> looked up, and if there is a token already in the cache, then the
> AuthenticateToken part is skipped and only the
> VerifyPlainTextPassword is called.
>
> In your case, when the message is received with the Username token
> containing the salted password,
> does that endpoint sign the message with that same token for another
> endpoint. Is it possible to describe
> your scenario a little bit, so that I can hopefully provide you with a
> little more advice?
>
> Hope this helps a bit.
>
> Sidd [MSFT]
>
> "Jeff Key" <spam@sliver.com> wrote in message
> news:O6I8fBjWEHA.3016@tk2msftngp13.phx.gbl...
>> Consider the following:
>>
>> SoapEnvelope envelope = new SoapEnvelope();
>>
>> UsernameToken token = new UsernameToken(username,
>> CryptoUtil.Encrypt(password), PasswordOption.SendPlainText);
>> envelope.Context.Security.Tokens.Add(token);
>>
>> DerivedKeyToken derivedKeyToken = new DerivedKeyToken(token);
>> envelope.Context.Security.Tokens.Add(derivedKeyToken);
>> envelope.Context.Security.Elements.Add(new
>> MessageSignature(derivedKeyToken));
>>
>> // Add content via envelope.SetBodyObject
>> // SendRequestResponse or SendOneWay
>>
>> (I've extended UsernameTokenManager to do the authentication on the
> server.)
>>
>> When the message is received, VerifyPlainTextPassword is called instead
>> of
>> AuthenticateToken. AuthenticateToken is only called if I don't sign.
>>
>> This has been a source of great pain, suffering, sleepless nights and
> broken
>> dreams. It worked in the TP.
>>
>> Can anyone give me a hand?
>>
>> Thanks,
>> -jk
>>
>>
>
>