Open the Visual Studio 2005 solution, MessageSecurity.sln, in the folder WCFHandsOnSecurityBasicsMessageSecurity. This solution consists of a derivatives calculator service like the one constructed in Chapter 2, as well as a .NET console application for hosting that service, and another .NET console application to serve as the client.

Examine the code in the static Main() function in the Program.cs file of the Client project of the MessageSecurity solution. It has the client invoke the derivatives calculator service twice, using a different endpoint each time. In calling the second endpoint, it offers credentials in the form of a username and password:

decimal result = 0;
using (DerivativesCalculatorClient proxy =
    new DerivativesCalculatorClient("DerivativesCalculatorServiceWindows"))
{
    proxy.Open();
    result = proxy.CalculateDerivative(
    [...]
    proxy.Close();
}
[...]
using (DerivativesCalculatorClient proxy =
    new DerivativesCalculatorClient("DerivativesCalculatorServiceUserName"))
{
    proxy.ClientCredentials.UserName.UserName = @"don";
    proxy.ClientCredentials.UserName.Password = @"hall";
    proxy.Open();
    result = proxy.CalculateDerivative(
    [...]
    proxy.Close();
}

Look at the app.config file of the Client project in the MessageSecurity solution to see how the first endpoint is configured. The pertinent elements of the configuration are reproduced in Listing 7.5. The endpoint is configured to use the predefined WSHttpBinding. That binding provides message security by default, using Kerberos or NTLM credentials to identify the senders, to sign and encrypt the messages, and to negotiate session-specific keys for a secure conversation.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.serviceModel>
   <client>
     <endpoint
       address="http://localhost:8000/Derivatives/Calculator"
       binding="wsHttpBinding"
       contract="DerivativesCalculator.IDerivativesCalculator"
       name="DerivativesCalculatorServiceWindows"/>
   </client>
  </system.serviceModel>
</configuration>

Also examine the app.config file of the Client project in the MessageSecurity solution to see how the second endpoint is configured, the endpoint for which a username and password are provided. The relevant portions of the configuration are in Listing 7.6. The predefined WSHttpBinding is used once again, but this time it is customized so as to present for authentication what the WS-Security specification refers to as a UsernameToken: a combination of a username and password (Kaler 2002). Because passing the username and password credentials unencrypted from the client to the service would compromise their security, the Windows Communication Foundation requires that whenever usernames and passwords are used for authentication, the service must provide an X.509 certificate for encrypting them or be configured to use transport security. The behavior that is incorporated into the configuration in Listing 7.6 waives the check that the Windows Communication Foundation would otherwise perform automatically to determine whether the certificate offered by the service had been revoked by the issuer.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
      <system.serviceModel>
            <client>
                  <endpoint
                        address=
"http://FabrikamEnterprises:8000/Derivatives/AnotherCalculator"
                binding="wsHttpBinding"
                bindingConfiguration="SecureMessageUserName"
                behaviorConfiguration="UserName"
                        contract="DerivativesCalculator.IDerivativesCalculator"
                        name="DerivativesCalculatorServiceUserName"/>
           </client>
           <bindings>
                 <wsHttpBinding>
                       <binding name="SecureMessageUserName">
                             <security mode="Message">
                                   <message clientCredentialType="UserName"/>
                             </security>
                       </binding>
                 </wsHttpBinding>
           </bindings>
           <behaviors>
               <endpointBehaviors>
                       <behavior name="UserName">
                            <clientCredentials>
                                  <serviceCertificate>
                                        <authentication
                                                 revocationMode="NoCheck"/>
                                  </serviceCertificate>
                            </clientCredentials>
                       </behavior>
               </endpointBehaviors>
           </behaviors>
      </system.serviceModel>
</configuration>

Look in the app.config file of the Host project of the MessageSecurity solution to see how the service endpoint that uses Kerberos or NTLM credentials to identify the users of clients is configured. The pertinent elements of that configuration are shown in Listing 7.7. The endpoint is simply configured to use the predefined WSHttpBinding, which, by default, anticipates users presenting Kerberos or NTLM to identify themselves.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
   <services>
     <service
name="DerivativesCalculator.DerivativesCalculatorServiceType">
        <endpoint
          address="Calculator"
          binding="wsHttpBinding"
          contract="DerivativesCalculator.IDerivativesCalculator"/>
        <host>
          <baseAddresses>
            <add
              baseAddress="http://localhost:8000/Derivatives/"/>
          </baseAddresses>
        </host>
      </service>
    </services>
   </system.serviceModel>
</configuration>

Also examine the app.config file of the Host project to see how the service endpoint that employs username and password combinations to identify the users of clients is configured. The relevant parts of the configuration are in Listing 7.8. This configuration also uses the predefined WSHttpBinding, but customizes it to use usernames and passwords to authenticate the users of clients, rather than Kerberos or NTLM credentials. A behavior is used to specify that the FabrikamEnterprises certificate is the certificate that the server is to provide for encrypting the transmission of username and password combinations from the client to the service. The behavior also specifies that a custom class for validating username and password combinations will be used, and identifies that class as the DerivativesCalculator.MyUserNamePasswordValidator class in the Host assembly. Ordinarily, the Windows Communication Foundation validates user names and passwords against Windows account information, but the option of identifying a custom class to validate those credentials against some other store is provided.

<?xml version="1.0" encoding="utf-8" ?>
  <configuration>
    <system.serviceModel>
      <services>
        <service
          name="DerivativesCalculator.DerivativesCalculatorServiceType"
          behaviorConfiguration="DerivativesCalculatorService">
          <endpoint
            address="AnotherCalculator"
            binding="wsHttpBinding"
            bindingConfiguration="SecureMessageUserName"
            contract="DerivativesCalculator.IDerivativesCalculator"/>
          <host>
            <baseAddresses>
              <add
                baseAddress="http://localhost:8000/Derivatives/"/>
            </baseAddresses>
          </host>
        </service>
      </services>
      <bindings>
        <wsHttpBinding>
          <binding name="SecureMessageUserName">
            <security mode="Message">
               <message clientCredentialType="UserName"/>
            </security>
          </binding>
        </wsHttpBinding>
      </bindings>
      <behaviors>
        <serviceBehaviors>
          <behavior name="DerivativesCalculatorService">
            <serviceCredentials>
              <userNameAuthentication
                userNamePasswordValidationMode="Custom"
                customUserNamePasswordValidatorType=
"DerivativesCalculator.MyUserNamePasswordValidator,Host"/>
                  <serviceCertificate
                    findValue="CN=FabrikamEnterprises"/>
            </serviceCredentials>
          </behavior>
        </serviceBehaviors>
      </behaviors>
   </system.serviceModel>
</configuration>

Look at the code for the custom class for validating user names and passwords in the MyUserNamePasswordValidator file of the Host project. The class derives from the abstract base, System.IdentityModel.Selectors.UserNamePasswordValidator, and overrides that base class’s sole abstract method, Validate(). That method is passed the username and password offered by the client. If the validation of the credentials fails, the Validate() method is expected to throw a System.IdentityModel.Tokens.SecurityTokenException. Otherwise, the client is presumed to have been authenticated by the credentials.

public class MyUserNamePasswordValidator : UserNamePasswordValidator
{
    public override void Validate(string userName, string password)
    {
        if ([...])
        {
            throw new SecurityTokenException("Unknown user.");
        }
        Console.Write("Credentials accepted. 
");
    }
}

Study the code of the service type, which is in the DerivativesCalculatorServiceType file of the DerivativesCalculatorService project. As the following snippet shows, if the credentials offered by the user map to a Windows account, the service prints out the name of the user of the client before responding to the client’s request.

decimal IDerivativesCalculator.CalculateDerivative(
    string[] symbols,
    decimal[] parameters,
    string[] functions)
{
    WindowsIdentity identity = ServiceSecurityContext.Current.WindowsIdentity;
    if (identity != null)
    {
        string name = identity.Name;
        if (!(string.IsNullOrEmpty(name)))
        {
            Console.WriteLine("User is {0}.", name);
        }
    }
    return new Calculator().CalculateDerivative(
        symbols, parameters, functions);
}

Choose Build, Build Solution from the Visual Studio 2005 menus.

Execute MessageSecurityHostinHost.exe.

Execute MessageSecurityClientinClient.exe. Once again, it would be more effective to do so under a different account from the one that is currently logged-in. To do so, right-click on the executable, choose Run As from the context menus that appears, and run the application with the credentials of some user who has permission to log in locally, but who is not the user that is currently logged in.

When the output in the console of the Host application signifies that the service is ready, enter a keystroke into the console of the Client application. The Client application will display results retrieved, first after offering Windows credentials to the service, and then after offering a username and password combination. In the first case, in which the client offers Windows credentials, the output in the console for the Host application will identify the user under whose account the Client application was executed.

Close both consoles.

Open the Visual Studio 2005 solution, Impersonation.sln, in the folder WCFHandsOnSecurityBasicsImpersonation. Like the solutions used earlier in this chapter, this one contains a .NET console application that uses a derivatives calculator service. That service is hosted, as usual, within a .NET console application called Host. However, the service actually delegates its work of calculating the values of derivatives to another derivatives calculator service hosted by a second .NET console application, which is called BackOfficeHost.

See how the client is configured by examining the app.config file in the Client project of the Impersonation solution. The configuration is shown in Listing 7.9. It incorporates a behavior associated with the endpoint that grants the service permission to impersonate the user of the client. The binding specified for the endpoint is the predefined WSHttpBinding, which by default will identify the user of the client to the service using Windows credentials.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.serviceModel>
    <client>
      <endpoint
        address="http://localhost:8000/Derivatives/Calculator"
        binding="wsHttpBinding"
        contract="DerivativesCalculator.IDerivativesCalculator"
        behaviorConfiguration="Windows"
        name="DerivativesCalculatorServiceWindows"/>
    </client>
    <behaviors>
      <endpointBehaviors>
        <behavior name="Windows">
          <clientCredentials>
            <windows
              allowedImpersonationLevel="Impersonation"/>
          </clientCredentials>
        </behavior>
      </endpointBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

Look at the code of the derivatives calculator service hosted by the Host application. The code for that service is in the DerivativesCalculatorServiceType.cs file in the Host project of the solution. The important parts of the code are in Listing 7.10. This code handles requests from the client, and delegates them to the derivatives calculator service hosted by the BackOfficeHost. The key element of the code is the Impersonation parameter passed to the System.ServiceModel.OperationBehavior attribute. The value of that parameter is set to System.ServiceModel.ImpersonationOption.Required, which signifies that the operation needs to impersonate the user of the client to access resources that it needs. Therefore, the binding of any endpoint that incorporates a contract implemented using this operation must have clients present Windows credentials for the service to authenticate their users because impersonation is possible only when the user of the client has been authenticated as a Windows user. If the binding does not conform to this requirement, the service will not start. Furthermore, in order for a client to invoke this operation through the Windows Communication Foundation, the client must permit the service to impersonate the user of the client.

[OperationBehavior(Impersonation=ImpersonationOption.Required)]
decimal IDerivativesCalculator.CalculateDerivative(
    string[] symbols,
    decimal[] parameters,
    string[] functions)
{
    [...]

    decimal result = 0;
    using (DerivativesCalculatorClient proxy =
        new DerivativesCalculatorClient("BackOfficeDerivativesCalculator"))
    {
        proxy.Open();
        result = proxy.CalculateDerivative(
            new string[] { "MSFT" },
            new decimal[] { 3 },
            new string[] { });
        proxy.Close();
    }
    return result;
}

Check how the service hosted by the Host application is configured to use the service that is hosted by the BackOfficeHost application. The configuration is in the app.config file of the Host project, and shown in the following snippet. The predefined WSHttpBinding is used, which, by default, will offer Windows credentials to authenticate the caller. In this case, the intermediary service will be offering the Windows credentials of the user of its own client, who it will be impersonating.

<client>
      <endpoint
            address="http://localhost:8020/Derivatives/Calculator"
               binding="wsHttpBinding"
            contract="DerivativesCalculator.IDerivativesCalculator"
            name="BackOfficeDerivativesCalculator"/>
</client>

Look at the code of the derivatives calculator service hosted by the BackOfficeHost application. That code is in the DerivativesCalculatorServiceType.cs file of the BackOfficeHost project. The pertinent elements are in this next snippet. The CalculateDerivative() method that will be invoked by the intermediary service hosted by the Host application has a System.Security.Permissions.PrincipalPermission attribute that restricts access to one particular user.

[PrincipalPermission(
      SecurityAction.Demand,
      Name = @"ws2k3r2082006DonHall")]
[OperationBehavior(Impersonation=ImpersonationOption.Allowed)]
decimal IDerivativesCalculator.CalculateDerivative(
      string[] symbols,
      decimal[] parameters,
      string[] functions)
{
      [...]
      return new Calculator().CalculateDerivative(
            symbols, parameters, functions);
}

Modify the System.Security.Permissions.PrincipalPermission attribute so that the name specified for the sole authorized user is that of a valid user on the computer that has been granted the right to log on locally, but is not the user that is currently logged on.

Choose Build, Build Solution from the Visual Studio 2005 menus.

Choose Debug, Start Debugging from the Visual Studio 2005 menus to start the Host application and the BackOfficeHost application.

Execute ImpersonationClientinClient.exe, and do so as the user that was selected as the sole user permitted to access the service hosted by the BackOfficeHost in step 6. Right-click on ImpersonationClientinClient.exe, choose Run As from the context menus, and select that user on the Run As dialog and enter that user’s credentials.

When the output in the consoles of the Host and BackOfficeHost applications indicates that the services hosted by those applications are available, enter a keystroke in the console of the Client application. The Client application should request that the service hosted by the Host application calculate the value of a derivative. That service should delegate the work of doing the calculation to the service hosted by the BackOfficeHost application, and the Client application should get a response. Evidently, the intermediary service hosted by the Host application is impersonating the user of the Client application because no other user is authorized to use the service Hosted by the BackOfficeHost application.

Close the consoles of all three applications.

Open the Visual Studio 2005 solution, Authorization.sln, in the folder WCFHandsOnSecurityBasicsAuthorization. The solution contains a .NET console application called Client that uses a derivatives calculator service hosted within another .NET console application called Host. The solution also contains a class library called CustomServiceAuthorizationManager.

Notice that the definition of the service’s contract, which is in the IDerivativesCalculator.cs file of both the Host and Client projects, exercises the option of explicitly providing a value for the Action parameter of the sole System.ServiceModel.OperationContract attribute applied to any of its methods:

[OperationContract(
    Action = "CalculateDerivative")]
decimal CalculateDerivative(
    string[] symbols,
    decimal[] parameters,
    string[] functions);

Whatever value is assigned to the Action parameter of a System.ServiceModel.OperationContract attribute must serve to uniquely identify the method to which the attribute is applied relative to the other methods of the service type. The reason is that the Windows Communication Foundation determines to which method of a service a message is to be directed by matching the Action header of the message to the value of the Action parameter of the method’s System.ServiceModel.OperationContract attribute.

Look at how the client is configured by examining the app.config file of the Client project. The configuration is like the one shown in Listing 7.6, so the client will offer a username and password for the service to use for authentication.

Study the app.config file of the Host project to see how the service is configured. It is reproduced in Listing 7.12. The service is configured with a set of behaviors that has the arbitrary name DerivativesCalculatorService. That set includes a System.ServiceModel.Description.ServiceCredentials behavior with its UserNameAuthentication property set to authenticate the credentials provided by the client using a custom validation routine rather than simply validating the credentials against Windows account information. Therefore, however authorization will be accomplished in this case, the mechanism must not be one that is restricted to use with Windows accounts.

How authentication is to be accomplished is defined by another behavior in the set, the System.ServiceModel.Description.ServiceAuthorization behavior. That behavior is configured to ignore any System.Security.Permissions.PrincipalPermission attributes that exist in the code, by virtue of having the value System.ServiceModel.Description.PrincipalPermissionMode.None assigned to its PrincipalPermissionMode property. The behavior also has a type assigned to its ServiceAuthorizationManagerType property. Any type assigned as the value of System.ServiceModel.Description.ServiceAuthorization behavior’s ServiceAuthorizationManagerType property must derive from System.ServiceModel.ServiceAuthorizationManager. The type that is assigned in this case is the DerivativesCalculator.MyServiceAuthorizationManager type in the CustomServiceAuthorizationManager assembly.

<?xml version="1.0" encoding="utf-8" ?>
   <configuration>
     <system.serviceModel>
       <services>
         <service
name="DerivativesCalculator.DerivativesCalculatorServiceType"
          behaviorConfiguration="DerivativesCalculatorService">
        <endpoint
          address="Calculator"
         binding="wsHttpBinding"
         bindingConfiguration="SecureMessage"
         contract="DerivativesCalculator.IDerivativesCalculator"/>
         <host>
           <baseAddresses>
             <add
               baseAddress="http://localhost:8000/Derivatives/" />
             <add
               baseAddress="net.tcp://localhost:8010/Derivatives/" />
           </baseAddresses>
         </host>
       </service>
     </services>
     <bindings>
       <wsHttpBinding>
         <binding name="SecureMessage">
           <security mode="Message">
              <message clientCredentialType="UserName"/>
           </security>
         </binding>
       </wsHttpBinding>
      </bindings>
      <behaviors>
        <serviceBehaviors>
          <behavior name="DerivativesCalculatorService">
            <serviceCredentials>
            <userNameAuthentication
              userNamePasswordValidationMode="Custom"
              customUserNamePasswordValidatorType=
"DerivativesCalculator.MyUserNamePasswordValidator,Host"/>
            <serviceCertificate
              findValue="CN=FabrikamEnterprises"/>
            </serviceCredentials>
            <serviceAuthorization
              principalPermissionMode="None"
              serviceAuthorizationManagerType=
"DerivativesCalculator.MyServiceAuthorizationManager,
[ic:ccc] CustomServiceAuthorizationManager"/>
            <serviceMetadata
              httpGetEnabled="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
   </system.serviceModel>
</configuration>

Look at the assemblies referenced by the Host project in the Authorization solution. An assembly called CustomServiceAuthorizationManager is not among them.

Look at the assemblies deployed in the same directory as the Host.exe assembly that is built from the Host project. That directory should be the WCFHandsOnSecurityBasicsAuthorizationHostin directory, and it contains an assembly called CustomServiceAuthorizationManager. The CustomServiceAuthorizationManager project in the solution is configured to copy the assembly that it builds into that directory. So, evidently, the reference in the configuration of the service to the DerivativesCalculator.MyServiceAuthorizationManager type in the CustomServiceAuthorizationManager assembly could be a reference to a type in any assembly that the .NET common language runtime loader can locate.

Study the code of the class that is assigned as the value, in the configuration of the service, to the ServiceAuthorizationManagerType property of the System.ServiceModel.Description.ServiceAuthorization behavior. That code is in the MyServiceAuthorizationManager.cs file of the CustomServiceAuthorizationManager project. It is reproduced in Listing 7.13. The code defines a type that derives from System.ServiceModel.ServiceAuthorizationManager and overrides its virtual CheckAccess() method. Because the type has been assigned as the value of the ServiceAuthorizationManagerType property of the System.ServiceModel.Description.ServiceAuthorization behavior, its CheckAccess() override will be invoked whenever the service type with which the behavior is associated receives a request. The CheckAccess() method is passed a System.ServiceModel.OperationContext object that conveys information about the request. In particular, the code for the method can use the System.ServiceModel.OperationContext object to ascertain which operation will be executed in response to the request, and everything that is known about the user on whose behalf the request was sent. This expression yields the Action header of the message that identifies the operation to be executed:

operationContext.IncomingMessageHeaders.Action

This expression retrieves the information about the user:

operationContext.ServiceSecurityContext.AuthorizationContext.ClaimSets

That information is in the form of a collection of System.IdentityModel.Claim.ClaimSet objects, and each of the objects in that collection consists of an array of System.IdentityModel.Claim.Claim objects, each of which represents some claim made about the user. Based on the operation that is to be executed, and based on what is known about the user, the code for the CheckAccess() method decides whether the user is authorized to have the operation executed. If the user is authorized, the CheckAccess() method returns true, and otherwise it returns false.

public class MyServiceAuthorizationManager: ServiceAuthorizationManager
{
    public override bool CheckAccess(OperationContext operationContext)
    {
        if (string.Compare(
                  operationContext.IncomingMessageHeaders.Action,
                  "CalculateDerivative",
                  true) == 0)
        {

            ReadOnlyCollection<ClaimSet> claimSets =
operationContext.ServiceSecurityContext.AuthorizationContext.ClaimSets;

            ClaimSet claimSet = claimSets[0];
            foreach (Claim claim in claimSet)
            {
                 if(string.Compare(
                   claim.ClaimType,
                   ClaimTypes.Name,
                   true)==0)
                 {
                     if (string.Compare(
                   claim.Right,
"http://schemas.xmlsoap.org/ws/2005/05/identity/right/identity",
                   true) == 0)
                     {
                         if (string.Compare(
                         (string)claim.Resource,
                         "don",
                         true) == 0)
                         {
                              return true;
                         }
                     }
                 }
            }
        }
        return false;
    }
}

Choose Debug, Start Debugging from the Visual Studio 2005 menus.

When the output in the console of the Host application confirms that the service is ready, enter a keystroke into the console of the Client application. The Client application should retrieve the value of a derivative from the service. It does so by offering a username and password to the service that the service authenticates using its custom validation routine. After authenticating the credentials proferred by the client, the service authorizes access to the derivatives calculation routine based on information from the authenticated credentials.

Choose Debug, Stop Debugging from the Visual Studio 2005 menus to terminate the applications.