Turning Off Principal Handling

I'm setting up a custom principal for the current thread based on the received messages, but the principal gets reset before the service operation is called. How do I stop this from happening?

What's likely happening here is that the PrincipalPermissionMode is still set to its default value. Most people don't want to get involved with how the current principal is chosen. Most people don't even want to get involved with how the current principal is consumed. As long as WCF sets things up to grant a reasonable set of permissions based on the caller, most people don't want to think about authorization.

On the other hand, some people care very deeply how the current principal is chosen. For example, if you have your own role based system for authorization, then you will want to get involved in the process. That's why WCF gives you a variety of options for controlling how the principal gets established.

The ServiceAuthorizationBehavior includes a setting called PrincipalPermissionMode to control setting the current principal. By default, the PrincipalPermissionMode is set to UseWindowsGroups. Your other options are to use ASP.NET roles, provide a callback for establishing a custom principal, or disable the automatic update to CurrentPrincipal by the service. Since this case already has some code to set the current principal, the right way to make that work is to disable the automatic update by setting PrincipalPemissionMode to None.

Next time: Tradeoffs of IIS Hosting

Comments

• Anonymous
  September 14, 2007
  Many services consist of more than one message processing strategy. Typically, you think of services