Programming WCF Services : Security - Intranet Application Scenario (part 7) - Identity Management, Callbacks

8. Identity Management

In the intranet scenario, after successful authentication, WCF will attach to the operation thread a principal identity of the type WindowsIdentity, which will have the value of its Name property set to the username (or Windows account) provided by the client. Since valid credentials are provided, the security call context’s two identities—the primary identity and the Windows identity—will be set to the same identity as the principal identity. All three identities will be considered authenticated. The identities and their values are shown in Table 1.

Table 1. Identity management in the intranet scenario
Identity	Type	Value	Authenticated
Thread principal	WindowsIdentity	Username	Yes
Security context primary	WindowsIdentity	Username	Yes
Security context Windows	WindowsIdentity	Username	Yes

Windows Roles Localization

If your application is deployed in international markets and you use Windows groups as roles, it’s likely the role names will not match. In the intranet scenario, the principal object attached to the thread accessing the service is of the type WindowsPrincipal:

public class WindowsPrincipal : IPrincipal
{
   public WindowsPrincipal(WindowsIdentity ntIdentity);

   //IPrincipal implementation
   public virtual IIdentity Identity
   {get;}
   public virtual bool IsInRole(string role);

   //Additional methods:
   public virtual bool IsInRole(int rid);
   public virtual bool IsInRole(WindowsBuiltInRole role);
}

WindowsPrincipal provides two additional IsInRole() methods that are intended to ease the task of localizing Windows NT groups. You can provide IsInRole() with an enum of the type WindowsBuiltInRole matching the built-in NT roles, such as WindowsBuiltInRole.Administrator or WindowsBuiltInRole.User. The other version of IsInRole() accepts an integer indexing specific roles. For example, a role index of 512 maps to the Administrators group. The MSDN Library contains a list of both the predefined indexes and ways to provide your own aliases and indexes to user groups.

Note that while the host processes retain their designated identities, the principal identity will be that of the caller. I call this behavior soft impersonation. When it is used in conjunction with role-based security, it largely negates the need to ever perform real impersonation and replace the security token with that of the client.

9. Callbacks

When it comes to security on the intranet, there are several key differences between normal service operations and callbacks. First, with a callback contract you can only assign a protection level at the operation level, not the callback contract level. For example, this protection-level constraint will be ignored:

[ServiceContract(CallbackContract = typeof(IMyContractCallback))]
interface IMyContract
{...}

//Demand for protection level will be ignored
[ServiceContract(ProtectionLevel = ProtectionLevel.EncryptAndSign)]
interface IMyContractCallback
{...}

Only the service contract designating the callback contract can set a contract-level protection constraint. WCF deliberately ignores the service contract attribute on the callback contract to avoid a potential conflict between two contract attributes that apply to the same channel.

You can take advantage of operation-level demand for a protection level as follows:

[ServiceContract(CallbackContract = typeof(IMyContractCallback))]
interface IMyContract
{...}

interface IMyContractCallback
{
   [OperationContract(ProtectionLevel = ProtectionLevel.EncryptAndSign)]
   void OnCallback();
}

All calls into the callback object come in with an unauthenticated principal, even if Windows security was used across the board to invoke the service. As a result, the principal identity will be set to a Windows identity with a blank identity, which will preclude authorization and role-based security.

While the callback does have a security call context, the Windows identity will be set to a WindowsIdentity instance with a blank identity, which will preclude impersonation. The only meaningful information will be in the primary identity, which will be set to the service host’s process identity and machine name:

class MyClient : IMyContractCallback
{
   public void OnCallback()
   {
      IPrincipal principal = Thread.CurrentPrincipal;
      Debug.Assert(principal.Identity.IsAuthenticated == false);

      ServiceSecurityContext context = ServiceSecurityContext.Current;
      Debug.Assert(context.PrimaryIdentity.Name == "MyHost/localhost");

      Debug.Assert(context.IsAnonymous == false);
   }
}