Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / ASP.NET / Web Services / February 2005

Tip: Looking for answers? Try searching our database.

WSE 2.0 SP2: UsernameTokens must be encrypted to request SCT?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
SA - 11 Feb 2005 00:51 GMT
Hi all,

In Keith Brown's article [1], I read

"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."

Is this actually the case? I am still running SP 1 of WSE 2.0 and will need
to change a lot of code.

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.

Is there a workaround available?

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

Signature


Sven.

William Stacey [MVP] - 11 Feb 2005 05:15 GMT
> "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
 


Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.