> "The Web Services Enhancements (WSE) team is so concerned about the misuse
> of Username tokens that as of SP2, the WSE 2.0 token-issuing framework will
> reject any request that contains an unencrypted Username token (one
> acceptable form of encryption is simply to use SSL). And there will be no
> configuration option to change this behavior. If you really want to relax
> this restriction, you'll need to write code to do it."
I am not sure what they are talking about with that either. I have SP2 and
can send UT and sign the message with them with SendPlain and SendHashed
using just the default UTM and it works. So not sure what they are talking
about. Anyone?
> I understand the issues involved with the use of UsernameTokens to sign and
> to encrypt. However, for my application, it's not feasible to give
> certificates to users, nor will they be on the same domain (so, no Kerberos
> either). Also, the business case just isn't valuable enough for anyone to
> really try hard to mess with the data.
If it does not matter, then don't even require a password or security. Just
keep it open. If it does require security, then don't use UTs unless you
are using SSL or have a SCT and can encrypt them. If you can't use certs to
get a SCT, have a look at my post on using just the public rsa key to get a
SCT at
http://spaces.msn.com/members/staceyw/Blog/cns!1pnsZpX0fPvDxLKC6rAAhLsQ!303.entry

Signature
William Stacey, MVP
http://mvp.support.microsoft.com
> Hi all,
>
[quoted text clipped - 19 lines]
>
> [1]
http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnwse/htm
l/securusernametoken.asp
Softwaremaker - 11 Feb 2005 06:52 GMT
William,
> I am not sure what they are talking about with that either. I have SP2 and
> can send UT and sign the message with them with SendPlain and SendHashed
> using just the default UTM and it works. So not sure what they are talking
> about. Anyone?
[WilliamT] I am not sure if you are using the UT in the context of the
SecurityTokenServiceClient. I think the statement above by Keith is wrt to
the SecurityTokenServiceClient. I quote:
The SecurityTokenServiceClient class will now automatically encrypt any
Username tokens included in a request. Similarly, the SecurityTokenService
class will automatically encrypt any username tokens included in a response.
Unless I am missing something as well, I dont think it forces a UNT
encryption if you are sending plain UNT as authentication credentials
The following methods have been added to the token issuing framework:
protected virtual void
SecurityTokenServiceClient.EnforceRequestUsernameTokenEncryption().
Called from EnforceRequestPolicy(), this method enforces the requirement
that any Username tokens in an RST message must be encrypted. The
issuerToken is used as the encrypting token. This method will throw an
exception if it cannot encrypt the UsernameTokens in an RST message.
Override this method to suppress this behavior.
protected virtual void
SecurityTokenService.VerifyRequestUsernameTokenEncryption().
Called from VerifyRequestPolicy(), this method verifies that tokens in an
RST message are encrypted. This method will throw an exception if it
encounters an unencrypted UsernameToken in an RST message.
Override this method to suppress this test.
protected virtual void
SecurityTokenService.EnforceResponseUsernameTokenEncryption().
Called from EnforceResponsePolicy(), this method enforces the requirement
that any Username tokens in an RSTR message must be encrypted. The
ResponseEncryptingToken is used as the encrypting token. This method will
throw an exception if it cannot encrypt the UsernameTokens in an RSTR
message.
Override this method to suppress this behavior.
protected virtual void
SecurityTokenServiceClient.VerifyResponseUsernameTokenEncryption().
Called from VerifyResponsePolicy(), this method verifies that tokens in an
RSTR message are encrypted. This method will throw an exception if it
encounters an unencrypted UsernameToken in an RSTR message.
Override this method to suppress this test.

Signature
Thank you.
Regards,
William T (Softwaremaker)
http://www.softwaremaker.net/blog
=========================================
> > "The Web Services Enhancements (WSE) team is so concerned about the misuse
> > of Username tokens that as of SP2, the WSE 2.0 token-issuing framework
[quoted text clipped - 8 lines]
> using just the default UTM and it works. So not sure what they are talking
> about. Anyone?
> > I understand the issues involved with the use of UsernameTokens to sign
> and
[quoted text clipped - 9 lines]
> get a SCT, have a look at my post on using just the public rsa key to get a
> SCT at
http://spaces.msn.com/members/staceyw/Blog/cns!1pnsZpX0fPvDxLKC6rAAhLsQ!303.entry
> > Hi all,
> >
[quoted text clipped - 23 lines]
> >
> > [1]
http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnwse/htm
l/securusernametoken.asp
William Stacey [MVP] - 11 Feb 2005 07:08 GMT
aah. Ok, that makes more sense. Thanks.

Signature
William Stacey, MVP
http://mvp.support.microsoft.com
> William,
>
[quoted text clipped - 81 lines]
> a
> > SCT at
http://spaces.msn.com/members/staceyw/Blog/cns!1pnsZpX0fPvDxLKC6rAAhLsQ!303.entry
> > > Hi all,
> > >
[quoted text clipped - 27 lines]
> > >
> > > [1]
http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnwse/htm
l/securusernametoken.asp
SA - 11 Feb 2005 16:42 GMT
> If it does not matter, then don't even require a password or security. Just
> keep it open. If it does require security, then don't use UTs unless you
> are using SSL or have a SCT and can encrypt them. If you can't use certs to
> get a SCT, have a look at my post on using just the public rsa key to get a
> SCT at
http://spaces.msn.com/members/staceyw/Blog/cns!1pnsZpX0fPvDxLKC6rAAhLsQ!303.entry
Interesting article, thanks. Need to work my way trough it (and all previous
ones...), but basically you're using a key file made with the StrongName
tool? Good idea...
I meant actually that we need to keep track of logins for "auditing" and
it's not a public web service either. So, we need some authentication
mechanism. Some customers might be able to use Kerberos or X.509, but most
won't. (this is for development of a commercial product)
Sidd - 15 Feb 2005 21:36 GMT
Hi William,
Yes the article is accurate in its description about using a
UsernameToken to sign the initial RST. In WSE2 SP2 we require the client to
have encrypted the username token somehow, either with a Servers Cert, or
with https, but sending a plain RST signed with a username token in plain is
bad news and many people were doing it.
Offcourse there are ways to work around that. Currently, the check is
made both at the client and the service, and as always you can override the
default behavior to disable this checking.
Hope this answers your question.
Thanks,
Sidd [MSFT]
> > If it does not matter, then don't even require a password or security.
> Just
[quoted text clipped - 4 lines]
> a
> > SCT at
http://spaces.msn.com/members/staceyw/Blog/cns!1pnsZpX0fPvDxLKC6rAAhLsQ!303.entry
> Interesting article, thanks. Need to work my way trough it (and all previous
> ones...), but basically you're using a key file made with the StrongName
[quoted text clipped - 4 lines]
> mechanism. Some customers might be able to use Kerberos or X.509, but most
> won't. (this is for development of a commercial product)
William Stacey [MVP] - 15 Feb 2005 21:39 GMT
Thanks Sidd.

Signature
William Stacey, MVP
http://mvp.support.microsoft.com