WCF service configured for Transport security shouldn't change Thread.CurrentPrincipal - by Jon Miller

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


7
0
Sign in
to vote
ID 369445 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 9/23/2008 2:27:09 PM
Access Restriction Public

Description

If you configure a WCF service to use Transport security, even if you explicitly set <transport clientCredentialType="None"/>, Thread.CurrentPrincipal is overwritten by WCF. This behavior is different than if you aren't using Transport security. i.e. you are using HTTP instead of HTTPS. Normally, this wouldn't be an issue, but, if you are running the service in a web application and have <serviceHostingEnvironment aspNetCompatibilityEnabled="true" /> you might be setting Thread.CurrentPrincipal manually. This can come in handy if you wanted to use a PrinicipalPermission such as the following to control access to a web method.

[PrincipalPermission(SecurityAction.Demand, Role = "Administrator")]
Sign in to post a comment.
Posted by Microsoft on 10/13/2008 at 12:52 PM
Thanks for your suggestion, I'll pass along your feedback. Currently the way to control the CurrentPrincipal is through principalPermissionMode.

-Yavor
Posted by Jon Miller on 10/1/2008 at 3:01 PM
Yavor,

Thanks for the tip. While setting principalPermissionMode="None" solves the problem to a certain extent, it doesn't truly solve the problem. For example, I might want to use principalPermissionMode="UseAspNetRoles" which works fine if you are using HTTP but not if you are using HTTPS. In my opinion, the behavior should be the same for both. If I set the following, I don't think it should set Thread.CurrentPrincipal on the back end. The way I'm interpreting the following code is that I want to use HTTPS for encryption/privacy, but, I'm not using client side certificate authentication. So, I think the credentials on the back end should be left untouched, the same way it is for normal HTTP.

<security mode="Transport">
<transport clientCredentialType="None"/>
</security>
Posted by Microsoft on 9/30/2008 at 7:52 PM
Hi jemiller0,

I was able set the following service behavior:

<serviceAuthorization principalPermissionMode="None" />

and it prevented WCF from overriding the principal with a blank if I set it in the constructor.

Please let me know if this fixes the problem.

Thanks,
-Yavor Georgiev
Program Manager
Connected Framework Team
Posted by Microsoft on 9/24/2008 at 11:46 PM
Thank you for your feedback, We are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com/)