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 2006

Tip: Looking for answers? Try searching our database.

WSE3 Credentials

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Euphilos - 14 Feb 2006 19:00 GMT
Hello,

I'm trying to use WSE 3 in a web service for authentication and
authorization.

I've created a custom UsernameTokenManager overriding VerifyToken to
validate the token against the database and setting the token principal to a
generic principal with all the needed information.

This goes ok, but when I'm trying to find out which user is currently
authenticated, in the web method, using
RequestSoapContext.Current.Credentials.UltimateReceiver.GetClientToken(Of
UsernameToken)().Principal, GetClientToken returns nothing (causing a null
reference exception).

The code above is used in the hands-on lab for WSE3 security, and seems to
work there. I guess I could set the thread principal in VerifyToken, but the
code above seemed the recommended way to go.

Thank you for your help,

Euphilos
Steven Cheng[MSFT] - 15 Feb 2006 06:47 GMT
Hi Euphilos,

Welcome to the MSDN newsgroup.

From your description, I understand you're building a custom
UsernameTokenManager for your ASP.NET webservice which uses WSE 3.0 to
secure the messages. Also, you create some custom GenericPrinciple
instances in the custom UsernameTokenManager's verifytoken method and
assign them to the current SoapRequestContext. However, in webmethod code,
you find that the
RequestSoapContext.Current.Credentials.UltimateReceiver.GetClientToken can
not return the custom principal you assigned and report null reference
exception, correct?

I've also performed some tests in my local environment and did find some
similiar problem. Actually, the null reference exception occurs when I
configure the webservice application to use username over certificate (sign
and encrypt message) assertion. If do not sign and encrypte the message(use
transport layer security), the UltimateReceiver.GetClientToken can return
the correct value.

Would you please also test the two conditions and let me know whether you
get the same result?  Meanwhile, I'll do some further research on this and
will update you if I get any new information.

Regards,

Steven Cheng
Microsoft Online Support

Signature

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Steven Cheng[MSFT] - 20 Feb 2006 09:33 GMT
Hi Euphilos,

After some further research and discussing with some other WSE guys. The
behavior you encounter is the expected one if you've turned on the
"establishSecurityContext"?  e.g:

<usernameForCertificateSecurity establishSecurityContext="true"

If this is the case, since the WSE runtime will cache the security context
token, it won't attach the token at the
RequestSoapContext.Current.Credentials.UltimateReceiver in each request.  
Instead, we can use the following code to retrieve the security token:

SecurityContextToken sct =
RequestSoapContext.Current.Credentials.GetSecurityContextToken();

 string username = sct.Principal.Identity.Name;

Hope this helps.

Regards,

Steven Cheng
Microsoft Online Support

Signature

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)


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



©2009 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.