Username authentication often receives the name direct authentication, as the client provides authentication credentials in the form of a username and password during the request to the service, and the service can validate or authenticate the credentials itself against an identity store without going to a third party or authentication broker. (See Figure 8-1.)

Figure 8.1. Username authentication

The main characteristics of username authentication are summarized in the following list:

In the WCF implementation of username authentication over message security, the client passes the credentials to the service as part of a secure message exchange. The messages in this case are protected using an X509 certificate provided by the service. This certificate also works as a mechanism for the client to authenticate the service as part of the mutual authentication process.

The service credentials (the X509 certificate) can be transmitted to the client during the first message exchange or using an out-of-band mechanism according to the value of the negotiateServiceCredential setting.

The mechanism for authenticating the user credentials against an identity store is implemented through the abstract class System.IdentityModel.Selectors.UsernamePasswordValidator in the System.IdentityModel.Selectors assembly:

public abstract class UserNamePasswordValidator
{
  public abstract void Validate(string userName, string password);
}

The signature of the only method available in this class is quite evident. The username and password received as part of the client credentials is passed by WCF to this class for validation. In case the credentials cannot be validated, it is the responsibility of this class to throw an exception.

WCF ships with two internal implementations of this class, System.IdentityModel.Selectors.MembershipProviderValidator for validating the credentials against an existing ASP.NET Membership provider, and System.IdentityModel.Selectors.NoneUsernamePasswordValidator for not validating anything. These two implementations can be accessed through public members in the base UsernamePasswordValidator class:

public abstract class UserNamePasswordValidator
{
  public static UserNamePasswordValidator

CreateMembershipProviderValidator(MembershipProvider provider);

  public static UserNamePasswordValidator None { get; }
}

The static method CreateMembershipProviderValidator returns an instance of the MembershipProviderValidator that wraps the MembershipProvider passed as an argument. The static property None returns an instance of the NonUsernamePasswordValidator class.

The following code snippet shows a simple implementation of this class that validates the username and password against hardcoded strings:

public class MyUserNamePasswordValidator : UserNamePasswordValidator
{
  public override void Validate(string userName, string password)
  {
    if (userName != "joe" || password != "bar")
      throw new
  SecurityTokenValidationException("The user could not be authenticated");

  }
}

If the username is different from "Joe," or the password is not "bar," it throws an exception so WCF will assume the client could not be authenticated.

However, the default behavior for authenticating username and password credentials in WCF is to validate them against the Windows account store. Unless you do not override this setting through a specific element <usernameAuthentication> under the service behavior <serviceCredentials> to use a UsernamePasswordValidator, WCF will always use the Windows account store:

<bindings>
      <wsHttpBinding>
        <binding name="HelloWorld">
          <security mode="Message">
            <message clientCredentialType="UserName"
                     negotiateServiceCredential="true"/>
          </security>
        </binding>
      </wsHttpBinding>
    </bindings>
    <behaviors>
      <serviceBehaviors>
        <behavior name="HelloWorld">
          <serviceCredentials>
            <userNameAuthentication userNamePasswordValidationMode=
"Windows|MembershipProvider|Custom"/>
          </serviceCredentials>
        </behavior>
      </serviceBehaviors>
    </behaviors>

The setting usernamePasswordValidationMode in the <usernameAuthentication> element allows changing the mode that WCF uses to authenticate the username credentials. Windows is the default value, but also supports MembershipProvider for using a ASP.NET membership provider (internally uses the already discussed MembershipProviderValidator) or Custom to specify a custom implementation of UsernamePasswordValidator in case you want to provide something not supported by the other options. (The MyUsernamePasswordValidation implementation is an example of a custom implementation.)

Based on the value you chose for this setting, you need to provide additional values for other related settings.

In validation mode, Windows supports three optional settings:

<serviceCredentials>
            <userNameAuthentication userNamePasswordValidationMode="Windows"
                                    cacheLogonTokens="true"
                                    cachedLogonTokenLifetime="00:01:00"
                                    maxCachedLogonTokens="10"/>
 </serviceCredentials>

The validation mode MembershipProvider requires an additional setting membershipProviderName to provide the name of an already configured ASP.NET membership provider. (That name should exist in the configured membership providers.)

<behavior name="HelloWorld">
      <serviceCredentials>
            <userNameAuthentication userNamePasswordValidationMode=
                 "MembershipProvider"
                 membershipProviderName="MyProvider"/>
     </serviceCredentials>
   </behavior>
 </serviceBehaviors>
<system.web>
    <membership>
      <providers>
        <add name="MyProvider" type="..."/>
      </providers>
    </membership>
</system.web>

Finally, the validation mode Custom requires the setting customUsernamePasswordValidatorType to specify the .NET type of the custom implementation:

<behavior name="HelloWorld">
  <serviceCredentials>
    <userNameAuthentication userNamePasswordValidationMode="Custom"
  customUserNamePasswordValidatorType=
"MyCustomUsernamePasswordValidator, MyAssembly"/>
   </serviceCredentials>
</behavior>

The X509 certificate used to protect the communication must be configured by using the <serviceCertificate> element within the <serviceCredentials> behavior as shown in this configuration fragment:

<behavior name="HelloWorld">
  <serviceCredentials>
    <serviceCertificate findValue="CN=WCFServer" storeLocation="LocalMachine"
storeName="My" x509FindType="FindBySubjectDistinguishedName"/>
    <userNameAuthentication userNamePasswordValidationMode="Windows"/>
  </serviceCredentials>
</behavior>

When you reference a X509 certificate either in the configuration section or the object model, you often need to specify different settings that WCF will use to resolve the certificate location in the Windows certificate store. These settings are summarized in Table 8-3.

Now that you have a basic understanding of the different settings required to run an end-to-end scenario with a username authentication schema, let's walk through a complete example for a service that returns the claims of the authenticated user.

namespace WCFBook.Samples
{
  [ServiceContract()]
  public interface IEchoClaims
  {
    [OperationContract]
    List<string> Echo();
  }
}
public class EchoClaims : IEchoClaims
{
  public List<string> Echo()
  {
    List<string> claims = new List<string>();

    foreach (ClaimSet set in
          OperationContext.Current
            .ServiceSecurityContext
            .AuthorizationContext
            .ClaimSets)
    {
      foreach (Claim claim in set)
      {
        claims.Add(string.Format("{0} - {1} - {2}",
                  claim.ClaimType,
                  claim.Resource.ToString(),
                  claim.Right));
     }
   }

   return claims;
  }

}

class Program
{
  static void Main(string[] args)
  {
    ServiceHost host = new ServiceHost(typeof(EchoClaims),
                    new Uri("http://localhost:8000"));

try
    {
      host.Open();

      Console.WriteLine("Service running....");
      Console.WriteLine("Press a key to quit");
      Console.ReadKey();
    }
    finally
    {
      host.Close();
    }
  }
}

static void Main(string[] args)
{
    Console.WriteLine("Enter a valid username");
    string username = Console.ReadLine();

    Console.WriteLine("Enter the password");
    string password = Console.ReadLine();

    EchoClaimsReference.EchoClaimsClient client = new
    Client.EchoClaimsReference.EchoClaimsClient();
    client.ClientCredentials.UserName.UserName = username;
    client.ClientCredentials.UserName.Password = password;

    try

{
        string[] claims = client.Echo();

        foreach (string claim in claims)
        {
            Console.WriteLine(claim);
        }
    }
    catch (TimeoutException exception)
    {
        Console.WriteLine("Got {0}", exception.GetType());
        client.Abort();
    }
    catch (CommunicationException exception)
    {
        Console.WriteLine("Got {0}", exception.GetType());
        client.Abort();
    }
}

Instead of validating the user credentials with the Windows account store, this variant describes how to configure the service to a custom membership provider as the identity store.

For the purpose of this example, you implement a basic ASP.NET membership provider. For more complex scenarios, you can reuse some of the built-in providers such as SqlMembershipProvider for validating credentials against a SQL database.

public class MyMembershipProvider : MembershipProvider
{

    public override bool ValidateUser(string username, string password)

{
        if (username != "joe" ||
            password != "bar")
        {
            return false;
        }

        return true;
    }
}

<system.web>
  <membership>
    <providers>
      <add name="MyMembershipProvider" type="Common.MyMembershipProvider, Common"/>
    </providers>
  </membership>
</system.web>

<serviceBehaviors>
  <behavior name="echoClaimsBehavior">
    <serviceCredentials>
      <serviceCertificate
        findValue="CN=WCFServer"
        storeLocation="LocalMachine"
        storeName="My"
        x509FindType="FindBySubjectDistinguishedName"/>
      <userNameAuthentication
        userNamePasswordValidationMode="MembershipProvider"
        membershipProviderName="MyMembershipProvider"/>
    </serviceCredentials>
    <serviceMetadata httpGetEnabled="true"/>
  </behavior>
</serviceBehaviors>

The last variant involves the implementation of a custom UsernamePasswordValidator class for validating the user credentials against a custom identity store.

public class MyUserNamePasswordValidator : UserNamePasswordValidator
{
  public override void Validate(string userName, string password)
  {
    if (userName != "joe" || password != "bar")
      throw new SecurityTokenValidationException("The user could not
      be authenticated");

  }
}

<serviceBehaviors>
  <behavior name="echoClaimsBehavior">
    <serviceCredentials>
      <serviceCertificate
        findValue="CN=WCFServer"
        storeLocation="LocalMachine"
        storeName="My"
        x509FindType="FindBySubjectDistinguishedName"/>
      <userNameAuthentication
        userNamePasswordValidationMode="Custom"
             customUserNamePasswordValidatorType=
              "Common.MyCustomUsernamePasswordValidator, Common"/>
    </serviceCredentials>
    <serviceMetadata httpGetEnabled="true"/>
 </behavior>

Username authentication over transport security is another classic example of direct authentication. The client provides credentials in the form of a username and password during the request to the service using any built-in transport authentication mechanism, such as basic authentication. The service can then validate or authenticate the credentials against an identity store without using a third party or authentication broker. In addition, all the messages and credentials exchanged between the client and service are protected with security mechanisms provided by the transport, such as SSL/TLS.

In case of SSL, the service credentials (the X509 certificate) are always transmitted to the client during the SSL handshake when the connection is established, and before any message is sent by the client to service.

The first WCF version did not include a way to validate the user credentials against a custom identity store — the credentials were always validated against the Windows account store. Version 3.5 introduced improvements in this aspect, allowing the configuration of the custom userNamePasswordValidator to change this default behavior when the services are not hosted in IIS.

Plugging a custom extension to validate the credentials against a custom identity store for IIS-hosted services can be accomplished by means of an extension at IIS level — such as a custom ASP.NET module or a WCF custom channel that emulates Basic Authentication. These alternatives are not addressed in detail in this book.

The next example is based on a service hosted in IIS that uses SSL for transport security and Basic Authentication to authenticate the clients. The client and service implementations are the same as for message authentication.

Step 1: Configure a Virtual Directory in IIS for SSL

Go to the Internet Information Services (IIS) Manager and configure a server certificate under the Bindings configuration of the default web site, as shown in Figure 8-2. (You can use the certificate created by the script included with the samples, WCFServer.)

Then configure the default web site to require SSL under the SSL settings properties. (See Figure 8-3.)

Figure 8.2. Virtual directory configuration

Figure 8.3. SSL Settings

Step 2: Create a Virtual Directory in IIS Configured with Basic Authentication

After SSL is configured for the default web site, you are ready to create a virtual directory to host the services. The virtual directory must also be configured for Basic Authentication as it will be the authentication mechanism that you use for authenticating the clients in the service. (See Figure 8-4.)

Figure 8.4. Basic Authentication settings

That can be accomplished in the authentication options of the virtual directory properties. (You also need to disable anonymous authentication for the virtual directory, which is the default option when a new virtual directory is created.)

Mutual X509 certificate authentication is typical of what is called brokered authentication, as the service trusts the client based on credentials issued by a third party — the authentication broker.

In this scenario, the client provides authentication credentials in the form of X509 certificates issued by a certificate authority (CA) in a public key infrastructure (PKI). The client application attaches the public key of the client's X509 certificate to the request message (or a reference to that certificate), and digitally signs the message with the client's private key. When the service receives the message, it verifies that the message signature is valid using the attached public key, and optionally performs additional validations to ensure that the X509 certificate provided by the client has not expired and was issued by a CA it trusts. The client is authenticated when all these validations pass successfully. (See Figure 8-5.)

Figure 8.5. Mutual certificate authentication

The main characteristics of X509 mutual authentication are summarized in the following list:

As it happens with any authentication mechanism based on message security, the client passes the credentials to the service as part of a secure message exchange. The messages in this case are protected using an X509 certificate provided by the service. This certificate also works as a mechanism for the client to authenticate the service as part of the mutual authentication process. The service credentials (the X509 certificate) can be transmitted to the client during the first message exchange or by using an out-of-band mechanism according to the value of the negotiateServiceCredential setting.

The strategy for authenticating X509 certificates is implemented in WCF through the abstract class System.IdentityModel.Selectors.X509CertificateValidator in the System.IdentityModel.Selectors assembly:

public abstract class X509CertificateValidator
{
  public abstract void Validate(X509Certificate2 certificate);
}

The X509 certificate received as part of the client credentials are passed by WCF to this class for validation. In case the credentials cannot be validated, it is the responsibility of this class to throw an exception.

WCF ships with four internal implementations of this class:

public abstract class X509CertificateValidator
{
  public static X509CertificateValidator ChainTrust { get; }
  public static X509CertificateValidator None { get; }
  public static X509CertificateValidator PeerOrChainTrust { get; }
  public static X509CertificateValidator PeerTrust { get; }
}

The following code shows a simple implementation of this class that validates the certificate subject name against hardcoded strings:

public class MyX509CertificateValidator : X509CertificateValidator
{
    public override void Validate(X509Certificate2 certificate)
    {
        if (certificate.Subject != "CN=WCFClient")
        {
            throw new SecurityTokenValidationException(
                "The X509 client certificate can not be authenticated");

        }
    }
}

If the certificate subject name is different from CN=WCFClient, it throws an exception so WCF assumes the client could not be authenticated.

The settings for changing the X509 client credentials validation mode WCF are available through the configuration element <clientCertificate/authentication> under the service behavior <serviceCredentials>:

<behaviors>
      <serviceBehaviors>
        <behavior name="echoClaimsBehavior">
          <serviceCredentials>
            <clientCertificate>

<authentication certificateValidationMode=
"None|PerTrust|ChainTrust|PerOrChainTrust|Custom"
                              revocationMode="NoCheck|Online|Offline"
                              />
            </clientCertificate>
          </serviceCredentials>
        </behavior>
      </serviceBehaviors>
    </behaviors>

The setting certificateValidatorMode in the <authentication> element allows changing the mode that WCF uses to authenticate the certificate credentials. None, PerTrust, ChainTrust, or PerChainTrust maps with the internal implementations of the validators that were already discussed. The value Custom allows configuring a custom implementation of X509CertificateValidator in case you want to provide something not supported by the other options. (The MyX509CertificatePasswordValidation implementation is an example of a custom implementation.)

Based on the value you chose for this setting, you will need to provide additional values for other related settings.

The validation modes PerTrust, ChainTrust, and PerChainTrust support two optional settings:

And finally, the validation mode Custom requires the setting customCertificateValidatorType to specify the .NET type of the custom validator implementation:

<serviceBehaviors>
        <behavior name="echoClaimsBehavior">
          <serviceCredentials>
            <clientCertificate>
              <authentication certificateValidationMode="Custom"
                              customCertificateValidatorType=
"WCFBook.Samples.MyX509CertificateValidator, MyAssembly"
                              />
            </clientCertificate>

</serviceCredentials>
        </behavior>
      </serviceBehaviors>

The X509 certificate used to protect the communication must be configured by using the <serviceCertificate> element within the <serviceCredentials> behavior as is shown in this configuration fragment:

<serviceBehaviors>
  <behavior name="echoClaimsBehavior">
    <serviceCredentials>
      <serviceCertificate
              findValue="CN=WCFServer"
              storeLocation="LocalMachine"
              storeName="My"
              x509FindType="FindBySubjectDistinguishedName"/>
      <clientCertificate>
        <authentication certificateValidationMode="None"/>
      </clientCertificate>
    </serviceCredentials>
    <serviceMetadata httpGetEnabled="true"/>
  </behavior>
</serviceBehaviors>

The instructions for referencing a certificate in this section are the same as seen in the username authentication scenario.

If you decide to buy certificates from a well-known certificate authority such as Verisign, Thawte, or Comodo, make sure that the certificates contain the following attributes:

KeyUsage:
Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment (f0)
Enhanced Key Usage: Client Authentication (1.3.6.1.5.5.7.3.2)

Most SSL certificates meet these requirements, so it might be a good idea to stick to a SSL in case you are not sure.

It is time now to walk through a complete example for a service that authenticates the certificates using a custom validator, and returns the claims of the authenticated certificate.

namespace WCFBook.Samples
{
  [ServiceContract()]
  public interface IEchoClaims

{
    [OperationContract]
    List<string> Echo();
  }
}
public class EchoClaims : IEchoClaims
{
  public List<string> Echo()
  {
    List<string> claims = new List<string>();

    foreach (ClaimSet set in
          OperationContext.Current
            .ServiceSecurityContext
            .AuthorizationContext
            .ClaimSets)
    {
      foreach (Claim claim in set)
      {
        claims.Add(string.Format("{0} - {1} - {2}",
                  claim.ClaimType,
                  claim.Resource.ToString(),
                  claim.Right));
     }
   }

   return claims;
  }

}

class Program
{
  static void Main(string[] args)
  {
    ServiceHost host = new ServiceHost(typeof(EchoClaims),
                    new Uri("http://localhost:8000"));
    try
    {
      host.Open();

      Console.WriteLine("Service running....");
      Console.WriteLine("Press a key to quit");
      Console.ReadKey();
    }

finally
    {
      host.Close();
    }
  }
}

public override void Validate(X509Certificate2 certificate)
    {
        if (certificate.Subject != "CN=WCFClient")
        {
            throw new SecurityTokenValidationException(
                "The X509 client certificate can not be authenticated");

        }
}

static void Main(string[] args)
{
    EchoClaimsReference.EchoClaimsClient client = new

Client.EchoClaimsReference.EchoClaimsClient();

    try
    {
        string[] claims = client.Echo();

        foreach (string claim in claims)
        {
            Console.WriteLine(claim);
        }
    }
    catch (TimeoutException exception)
    {
        Console.WriteLine("Got {0}", exception.GetType());
        client.Abort();
    }
    catch (CommunicationException exception)
    {
        Console.WriteLine("Got {0}", exception.GetType());
        client.Abort();
    }
}

client.ClientCredentials.ClientCertificate.SetCertificate(
    StoreLocation.LocalMachine,
    StoreName.My,
    X509FindType.FindBySubjectDistinguishedName,
    "CN=WCFClient");

Kerberos authentication is another example of brokered authentication, where the service trusts the client based on certain credentials (a Kerberos ticket) issued by a third party.

In this scenario, the client provides authentication credentials in the form of a Kerberos ticket issued by a Kerberos Key Distribution Center (KDC).

Describing how Kerberos works in detail is beyond the scope of this book. However, it is important to understand that the client must be first authenticated against the broker, the KDC, and have access to a Kerberos ticket before it can request access to a service.

When Kerberos authentication is used, the client application requests a service ticket from a KDC for communicating with a specific service. The KDC creates a new session key and service ticket on behalf of the client's request. The ticket is encrypted with a key that is only known by the service (the service's master key). After the client receives the ticket and the session key, it uses both to create a Kerberos security token that will be included as the client credentials in the request message to the service. The session key is not included in the token, it is only included in the service ticket, which is what the service uses to validate the token.

The client protects the request message (signs and optionally encrypts the message) for the service using the session key, and includes the Kerberos token as client credentials. The service receives the request message, uses its master key to decrypt the service ticket found in the security token, and retrieves the session key. The session key is used to verify the message signature and optionally decrypts the message. Optionally, the service returns a response to the client. To provide mutual authentication in this scenario, the response should contain information that is encrypted with the session key to prove to the client that the service knows the session key.

The main characteristics of Kerberos authentication are summarized in the following list:

The negotiateServiceCredential setting works slightly differently in Kerberos compared to the rest of authentication schemas that use X509 certificates as service credentials. When this setting is set to false, the account running the service process must be associated with a Kerberos service principal name (SPN). To accomplish this, the service should run under the network service account or local system account. Alternatively, a SPN should be associated to the account using the SetSpn.exe tool. In either case, the client must specify the correct SPN in the endpoint identity as in the next sample:

<client>
    <endpoint address="http://localhost:8000/EchoClaims"
                  binding="wsHttpBinding"
                  bindingConfiguration="echoClaimsBinding"
                  contract="EchoClaimsReference.IEchoClaims"
                  name="WSHttpBinding_IEchoClaims"
                  behaviorConfiguration="echoClaimsBehavior">
    <identity>
      <servicePrincipalName value="HOST/MyMachine"/>
    </identity>
  </endpoint>
</client>

Kerberos authentication does not provide any kind of high-level class to validate the received credentials you have with Username and Certificate. The validation can be done, but at a much deeper level in the WCF stack with a custom SecurityTokenAuthenticator — this kind of extensibility point is not discussed in this chapter.

Let's walk through a complete example for a service that authenticates clients using Kerberos, and returns after the claims are extracted from the WCF security context.

namespace WCFBook.Samples
{
  [ServiceContract()]
  public interface IEchoClaims
  {
    [OperationContract]
    List<string> Echo();
  }
}
public class EchoClaims : IEchoClaims
{
  public List<string> Echo()
  {
    List<string> claims = new List<string>();

    foreach (ClaimSet set in
          OperationContext.Current
            .ServiceSecurityContext
            .AuthorizationContext
            .ClaimSets)
    {
      foreach (Claim claim in set)
      {
        claims.Add(string.Format("{0} - {1} - {2}",
                  claim.ClaimType,
                  claim.Resource.ToString(),
                  claim.Right));
     }
   }

   return claims;
  }

}

class Program
{
  static void Main(string[] args)
  {
    ServiceHost host = new ServiceHost(typeof(EchoClaims),
                    new Uri("http://localhost:8000"));
    try
    {
      host.Open();

      Console.WriteLine("Service running....");
      Console.WriteLine("Press a key to quit");
      Console.ReadKey();
    }
    finally
    {
      host.Close();
    }
  }
}

static void Main(string[] args)
{
    EchoClaimsReference.EchoClaimsClient client = new
    Client.EchoClaimsReference.EchoClaimsClient();

    try
    {
        string[] claims = client.Echo();

        foreach (string claim in claims)
        {
            Console.WriteLine(claim);
        }
    }
    catch (TimeoutException exception)
    {
        Console.WriteLine("Got {0}", exception.GetType());
        client.Abort();
    }
    catch (CommunicationException exception)
    {
        Console.WriteLine("Got {0}", exception.GetType());
        client.Abort();
    }
}

Role-based authorization is not something new that WCF brings to the scene; it has been available since the beginning in the .NET platform. The idea is that you associate a list of roles with a user, and then at runtime, the service implementation can use that list to take authorization-related decisions. An application can get the roles assigned to the user from different places or stores (such as a database or Azman), or they can be inferred from the Windows groups where the user is a member.

In the .NET world, the user identity and the roles assigned to that identity in a specific context are represented by the interfaces System.Security.IIdentity and System.Security.IPrincipal respectively.

A System.Security.IIdentity implementation class provides information about the name of the user (Name), whether he was authenticated (IsAuthenticated), and how he was authenticated (AuthenticationType):

public interface IIdentity
{
  string AuthenticationType { get; }
  bool IsAuthenticated { get; }
  string Name { get; }
}

On the other hand, an implementation of the System.Security.IPrincipal class contains a reference to the user identity (IIdentity) and must provide a method to verify whether the user belongs to a specific role:

public interface IPrincipal
{
  bool IsInRole(string role);
  IIdentity Identity { get; }
}

Some implementations are provided out of the box in the .NET Framework; for example, you can find the System.Security.WindowsIdentity and System.Security.WindowsPrincipal implementations for representing a Windows user, or a more generic implementation for any purpose in the classes System.Security.GenericIdentity and System.Security.GenericPrincipal.

A security principal is typically attached to the currently executing thread in your application. This is through the static property CurrentPrincipal in the System.Threading.Thread class. One part of the application is responsible for initializing that property, so the rest of the application can grab it from there and use it to perform any authorization code.

WCF works in the same way — the <serviceAuthorization> behavior controls the creation of a System.Security.IPrincipal instance and associates it to the thread handling the current request. When the clients have been Windows authenticated, WCF tries to populate the Thread.CurrentPrincipal with a Windows principal. With other authentication types, you have a choice between getting the roles from an ASP.NET role provider and implementing a custom authorization policy to provide a principal implementation (a generic principal in most cases).

In addition to the method IsInRole available in the user principal to perform role-based security checks, there is an attribute PermissionAttribute that allows you to annotate your service operations with role requirements. When this attribute is set for a specific operation, the security subsystem in the .NET CLR checks whether the principal attached to the current thread meets the requirements specified in the attribute. If the requirements are not met, a SecurityException is thrown prior to executing the service operation. WCF catches and converts this exception into an Access Denied fault before returning a response to the client.

The following code snippets show authorization code using the PrincipalPermission attribute, and the equivalent version using the Principal.IsInRole method:

public class Service : IService
{
    [PrincipalPermission(SecurityAction.Demand, Role = "Administrators")]
    public string DoOperation() {
    {
        return ...;
    }
}
public class Service : IService
{
    public string DoOperation() {
    {
        if (Thread.CurrentPrincipal.IsInRole("Administrators"))
        {
            return ...
        }
        else
        {
            throw new SecurityException();
        }

    }
}

As you can see, the use of the System.Security.PrincipalPermission attribute requires that you hardcode any possible group names when the service operation is being developed.

public class MyCustomRoleProvider : RoleProvider
{
    public override string[] GetRolesForUser(string username)
    {
        if (username == "joe")
        {
            return new string[] { "administrators" };
        }
        else
        {
            return new string[] { "users" };
        }
    }

    public override bool IsUserInRole(string username, string roleName)
    {
        return GetRolesForUser(username).Contains(roleName);
    }

    #region Omitted
    #endregion

}

<behaviors>
      <serviceBehaviors>
        <behavior name="echoClaimsBehavior">
          <serviceAuthorization
              principalPermissionMode="UseAspNetRoles"

roleProviderName="MyRoleProvider"/>
        </behavior>
      </serviceBehaviors>
 </behaviors>
<system.web>
    <roleManager enabled="true">
      <providers>
        <add name="MyRoleProvider" type="Common.MyCustomRoleProvider, Common"/>
      </providers>
    </roleManager>
</system.web>

<behaviors>
      <serviceBehaviors>
        <behavior name="echoClaimsBehavior">
          <serviceAuthorization
              principalPermissionMode="Custom">
            <authorizationPolicies>
              <add policyType="Common.CustomAuthorizationPolicy, Common"/>
            </authorizationPolicies>
          </serviceAuthorization>
        </behavior>
      </serviceBehaviors>

</behaviors>

You know that WCF passes the claims associated to the authenticated credentials, and the claims created in the custom authorization policies as part of the security context to the operation. Therefore, you can use all the flexibility that claims provide to represent identity information or individual rights to implement authorization code in the service operations.

All the claim sets that were generated prior to the service operation execution are available in WCF through the authorization context.

WCF provides access to the authorization context via the thread-static ServiceSecurityContext, which represents a container for claim sets, authorization policies, and current user identities:

public class ServiceSecurityContext
{
    public AuthorizationContext AuthorizationContext { get; }

public ReadOnlyCollection<IAuthorizationPolicy> AuthorizationPolicies { get; }
    public static ServiceSecurityContext Current { get; }
    public bool IsAnonymous { get; }
    public IIdentity PrimaryIdentity { get; }
    public WindowsIdentity WindowsIdentity { get; }
}

The service operation can simply enumerate the claim sets received as part of the authorization context to verify whether the user has permissions to execute an action or not:

public class Service : IService
{
    public void DoAction()
    {
        bool isFound = false;

        foreach (ClaimSet cs in OperationContext
            .Current
            .ServiceSecurityContext
            .AuthorizationContext
            .ClaimSets)
        {
            foreach (Claim claim in cs.FindClaims("urn:Group",
Rights.PossessProperty))
            {
                if (claim.Resource.ToString().Equals("administrator",
StringComparison.InvariantCultureIgnoreCase))
                {
                    isFound = true;
                    break;
                }
            }
        }

        if (!isFound)
        {
            throw new SecurityException("You are not authorized");
        }

    }

}

In the previous example, the service operation looks for an specific claim "urn:Group" with a resource value equal to "administrator". If that claim is not found, an exception is thrown as the user does not have permission to execute the operation.

You have seen so far how to use the user roles or claims in the service operation to implement authorization logic. However, in some cases, you might want to centralize all that authorization logic into one place and use it for every incoming request — without spreading it over all the service operations.

For that purpose, WCF provides a specific extensibility point known as the authorization manager. A service authorization manager is a class that derives from System.ServiceModel.ServiceAuthorizationManager and overrides the protected method CheckAccessCore to run custom authorization code for each request:

public class ServiceAuthorizationManager
{
    public virtual bool CheckAccess(OperationContext operationContext);
    public virtual bool CheckAccess(OperationContext operationContext,
ref Message message);

    protected virtual bool CheckAccessCore(OperationContext operationContext);

    protected virtual ReadOnlyCollection<IAuthorizationPolicy>
GetAuthorizationPolicies(OperationContext operationContext);
}

You can override any of the virtual methods in this class; however, WCF always calls the CheckAccessCore method.

That method receives the WCF operation context as an argument, so your authorization logic can either inspect the incoming message or the user authentication claims for enforcing authorization logic (or roles if you want to use role-based authorization logic). The result of the authorization logic is returned in that method, "true" when access is granted and "false" when it is denied.

The following code example uses the authentication claims to make an authorization decision:

public class MyAuthorizationManager : ServiceAuthorizationManager
{
    protected override bool CheckAccessCore(OperationContext operationContext)
    {
        bool isFound = false;

        foreach (ClaimSet cs in OperationContext
            .Current
            .ServiceSecurityContext
            .AuthorizationContext
            .ClaimSets)
        {
            foreach (Claim claim in
cs.FindClaims("urn:Group", Rights.PossessProperty))
            {
                if (claim.Resource.ToString().Equals("administrators",
StringComparison.InvariantCultureIgnoreCase))
                {
                    isFound = true;
                    break;
                }
            }
        }

        if (!isFound)
        {

return false;
        }

        return true;
    }

}

A custom authorization manager implementation can be configured in WCF using the serviceAuthorizationManagerType attribute in the <serviceAuthorization> behavior:

<behaviors>
  <serviceBehaviors>
    <behavior name="serviceBehavior">
      <serviceAuthorization
            serviceAuthorizationManagerType=
"Common.MyAuthorizationManager, Common"/>
    </behavior>
  </serviceBehaviors>

</behaviors>

Although using some information in the message content (SOAP body) is not recommended for performance reasons, you should keep in mind that messages in WCF are always read once. That means that you have to create a copy first before reading the content. That can be accomplished using the following code (not recommended for large or streamed messages):

MessageBuffer buffer = operationContext
                .RequestContext
                .RequestMessage
                .CreateBufferedCopy(int.MaxValue);