Programming WCF Services : Security - Intranet Application Scenario (part 3) - Identities, The Security Call Context

10/15/2013 7:41:36 PM

4. Identities

All Windows processes run with an authenticated security identity, and the process hosting a WCF service is no different. The identity is actually a Windows account whose security token is attached to the process (and to every thread in the process). However, it is up to the application administrator to decide which identity to use. One option is to have the host run with an interactive user identity; that is, the identity of the user who launched the host process. An interactive identity is typically used when self-hosting and is ideal for debugging, because the debugger will automatically attach itself to the host process when launched from within Visual Studio. However, relying on an interactive identity is impractical for deployment on a server machine, where there will not necessarily be a logged-on user, and if there is a logged-on user that user may not have the necessary credentials to perform the requested work. For production deployment, you typically rely on a designated account, which is a preset Windows account used primarily by your service or services. To launch the service under a designated account, you can use the “Run as” shell option. However, “Run as” is useful only for simple testing. You can also have an NT service as your host and use the Control Panel Services applet to assign a designated identity to the host. If you’re hosting in IIS 5/6 or the WAS, you can use those environments’ configuration tools to assign a designated identity to the process from the pool.

4.1. The IIdentity interface

In .NET, the IIdentity interface (from the System.Security.Principal namespace) represents a security identity:

public interface IIdentity
string AuthenticationType
bool IsAuthenticated
string Name

The interface lets you know whether the identity behind the interface is authenticated (and, if so, which authentication mechanism was used) and allows you to obtain the name of the identity. Out of the box, WCF takes advantage of three implementations of IIdentity offered by .NET: WindowsIdentity, GenericIdentity, and X509Identity. The WindowsIdentity class represents a Windows account. The GenericIdentity class is a general-purpose class whose main use is to wrap an identity name with an IIdentity. With both GenericIdentity and WindowsIdentity, if the identity name is an empty string, that identity is considered unauthenticated, and any other non-zero-length name is considered authenticated. Finally, X509Identity is an internal class that represents an identity that was authenticated using an X509 certificate. The identity behind an X509Identity is always authenticated.

4.2. Working with WindowsIdentity

The WindowsIdentity class offers a few useful methods above and beyond the mere implementation of IIdentity:

public class WindowsIdentity : IIdentity,...
public WindowsIdentity(string sUserPrincipalName);
public static WindowsIdentity GetAnonymous();
public static WindowsIdentity GetCurrent();
public virtual bool IsAnonymous
public virtual bool IsAuthenticated
public virtual string Name
//More members

The IsAnonymous Boolean property indicates whether the underlying identity is anonymous and the GetAnonymous() method returns an anonymous Windows identity, typically used for impersonation to mask the real identity:

WindowsIdentity identity = WindowsIdentity.GetAnonymous();
Debug.Assert(identity.Name == "");
Debug.Assert(identity.IsAuthenticated == false);
Debug.Assert(identity.IsAnonymous == true);

The GetCurrent() static method returns the identity of the process where it is called. That identity is always non-anonymous and authenticated:

WindowsIdentity currentIdentity = WindowsIdentity.GetCurrent();
Debug.Assert(currentIdentity.Name != "");
Debug.Assert(currentIdentity.IsAuthenticated == true);
Debug.Assert(currentIdentity.IsAnonymous == false);

5. The Security Call Context

Every operation on a secured WCF service has a security call context. The security call context is represented by the class ServiceSecurityContext, defined as:

public class ServiceSecurityContext
public static ServiceSecurityContext Current
public bool IsAnonymous
public IIdentity PrimaryIdentity
public WindowsIdentity WindowsIdentity
//More members

The main use for the security call context is for custom security mechanisms, as well as analysis and auditing. While it is presented here in the context of the intranet scenario, all other secured scenarios have use for the security call context as well.

Note that in spite of its name, this is the security context of the call, not the service. Two operations on the same service can definitely have different security call contexts.

The security call context is stored in the TLS, so every method on every object down the call chain from the service can access the security call context, including your service constructor. To obtain your current security call context, simply access the Current static property. Another way of accessing the security call context is via the ServiceSecurityContext property of the OperationContext:

public sealed class OperationContext : ...
public ServiceSecurityContext ServiceSecurityContext
//More members

Regardless of which mechanism you use, you will get the same object:

ServiceSecurityContext context1 = ServiceSecurityContext.Current;
ServiceSecurityContext context2 = OperationContext.Current.ServiceSecurityContext;
Debug.Assert(context1 == context2);


Your service has a security call context only if security is enabled. When security is disabled, ServiceSecurityContext.Current returns null.

The PrimaryIdentity property of ServiceSecurityContext contains the identity of the immediate client up the call chain. If the client is unauthenticated, PrimaryIdentityIIdentity with a blank identity. When Windows authentication is used, the PrimaryIdentity property will be set to an instance of WindowsIdentity. will reference an implementation of

The WindowsIdentity property is meaningful only when using Windows authentication, and it will always be of the type WindowsIdentity. When valid Windows credentials are provided, the WindowsIdentity property will contain the corresponding client identity and will match the value of PrimaryIdentity.


The constructor of a singleton service does not have a security call context, since it is called when the host is launched, not as a result of a client call.

Top 10
Review : Sigma 24mm f/1.4 DG HSM Art
Review : Canon EF11-24mm f/4L USM
Review : Creative Sound Blaster Roar 2
Review : Philips Fidelio M2L
Review : Alienware 17 - Dell's Alienware laptops
Review Smartwatch : Wellograph
Review : Xiaomi Redmi 2
Extending LINQ to Objects : Writing a Single Element Operator (part 2) - Building the RandomElement Operator
Extending LINQ to Objects : Writing a Single Element Operator (part 1) - Building Our Own Last Operator
3 Tips for Maintaining Your Cell Phone Battery (part 2) - Discharge Smart, Use Smart
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 1)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 2)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 3)
Popular Tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8