Chapter 10 - Intranet – Web to Remote WCF Using Transport Security (Trusted Subsystem, HTTP)

- J.D. Meier, Carlos Farre, Jason Taylor, Prashant Bansode, Steve Gregersen, Madhu Sundararajan, Rob Boucher

Applies To

  • Microsoft® Windows Communication Foundation (WCF) 3.5

Scenario

In this scenario, your users have Windows accounts and use a Web client to connect over the intranet to an ASP.NET application on an IIS server. The ASP.NET application makes calls to the WCF Service over HTTP. The business logic called by the WCF Service is backed by a SQL Server data store. The ASP.NET application, the WCF Service and the SQL Server data store are all part of a trusted subsystem. The basic model for this application scenario is shown in the following figure.

Ch10scenario.jpg

Key Characteristics

This scenario applies to you if:
  • Your users have browsers supporting Integrated Windows Authentication.
  • Your user accounts are in Active Directory within a domain.
  • Your user roles are Windows Groups.
  • Your users are accessing the web client from within the domain.
  • The business logic behind your WCF Service does not require fine-grained authorization.
  • Your ASP.NET application and WCF Service transmit sensitive data over the network that needs to be protected.
  • The ability to host the WCF Service in IIS is more important than a high performance connection between the ASP.NET application and the WCF Service.
  • Support for interoperability with non WCF clients is more important than a high performance connection between the ASP.NET application and the WCF Service.

Solution


Ch10solution.jpg

Solution Summary Table

In this solution you will:
  • Use domain credentials to authenticate clients against an Active Directory user store.
  • Use a service account to call WCF from the ASP.NET application. The WCF Service uses Windows Authentication.
  • Use a service account to call the SQL Server from WCF. The SQL Server uses Windows Authentication.
  • Use SSL to protect sensitive data between the Web client and IIS.
  • Use Transport security to protect sensitive data between the ASP.NET application and the WCF Service.
  • Optionally, use IPSec to protect sensitive data between the WCF Service and SQL Server.
  • Use wsHttpBinding to provide support for interoperability and allow the service to be hosted in IIS.
  • Host WCF in IIS.

Note: Due to a limitation with tables on this site, the code in the tables below may be run together when in the same cell. If this is a problem for you, please comment the workitem at
http://www.codeplex.com/CodePlex/WorkItem/View.aspx?WorkItemId=17004

Web Server

Checks Example
IIS - Configuration
A dedicated application pool is used and configured to run under a custom service account. Use a domain account if possible.
The Web application is configured to run under the service account. Assign the Web application to the custom application pool.
Service Principal Name is created if the service account used in the ASP.NET application pool is a custom domain identity. Create an SPN for both the DNS and NETBIOS machine name. setspn -a HTTP//WebServer.domain.com customDomainAccount setspn -a HTTP//WebServer customDomainAccount
IIS - Authentication
The IIS virtual directory is configured to use Windows Integrated Authentication. Users will be authenticated with Windows authentication.
Anonymous access is disabled.


ASP.NET - Authentication
ASP.NET is configured for Windows Integrated Authentication. The Web application will authenticate the users. <authentication mode = "Windows" >
ASP.NET - Authorization
If you have roles in your application, then use URL authorization. Use the <location> attribute to configure authorization settings for specific folders.Authorized users have access to specific folders and pages. <authorization> <allow roles="domainName\RoleName" /> <deny users="*" /> </authorization>
Role Manager is enabled and Role-checks are performed using Role Manager API. Original users are authorized using the Windows groups before calling in WCF Service. <roleManager enabled="true" defaultProvider= "AspNetWindowsTokenRoleProvider"/>


WCF Proxy - Configuration
ASP.NET has a proxy reference to the WCF Service. The application has access to the WCF metadata to create a service reference. WCFTestService.MyServiceClient proxy = new WCFTestService.MyServiceClient();
Proxy invokes services with the security context of the ASP.NET process identity. The proxy will automatically invoke WCF operations using the security context of the service account. proxy.GetData("data"); proxy.Close();
The Root Ca of the certificate is installed in the Trusted Root Certification Authorities store of the user machine, either in Local Machine or Local User. You need to install the root ca because transport security performs trust chain validation. If the certificate comes from a known issuer, such as Verisign, this is unnecessary.
WCF Proxy - Caller Identity
For auditing purposes, the identity of the caller can be passed in custom message headers. Use transport security to protect against spoofing attacks. using ( OperationContextScope scope = new OperationContextScope(proxy.InnerChannel)) { string identity = ((WindowsIdentity)HttpContext.Current.User.Identity).Name; MessageHeader<string> headerIdentity = new MessageHeader<string>(identity); MessageHeader untypedMessageHeader = headerIdentity.GetUntypedHeader("identity", "ns"); OperationContext.Current.OutgoingMessageHeaders.Add(untypedMessageHeader); TextBox1.Text = proxy.GetData("data"); }


Application Server

Checks & More Info Example
IIS - Configuration
A dedicated application pool is used and configured to run under a custom service account. Use a domain account if possible.
The WCF Service is configured to run under the service account. Assign the WCF Service to the custom application pool.
Service Principal Name is created if the service account used in the ASP.NET application pool of WCF Service is a custom domain identity. Create an SPN for both the DNS and NETBIOS machine name. setspn -a HTTP//WCFServer.domain.com customDomainAccount setspn -a HTTP//WCFServer customDomainAccount
Certificate is installed in personal store of LocalMachine. The certificate needs to match the DNS or netbios machine name of the application server.
Certificate is configured in the Web site of the application. Certificate is configured in the Web site for transport security using SSL.
The virtual directory is configured to use SSL. SSL is configurable per virtual directory bases.
The Root CA of the certificate is installed in the Trusted Root Certification Authorities store of the application machine either in Local Machine or Local User.You need to install the Root CA because transport security performs trust chain validation. If the certificate comes from a known issuer, such as Verisign, this is unnecessary.
IIS - Authentication
The IIS virtual directory is configured to use Anonymous access.


Checks & More Info Example
WCF Service - Configuration
Configure the WCF Service with wsHttpbinding. The wsHttpBinding uses the http protocol and provides full support for SOAP security, transactions, reliability and interoperability. <wsHttpBinding> <binding name="httpsendpointconfig"> <security mode="Transport"> <transport clientCredentialType="Windows" /> </security> </binding> </wsHttpBinding>
Service Metadata is configured in service behavior. httpGetEnabled is disabled and httpsGetEnabled is enabled. This is required so that client can add reference to the WCF Service using SvcUtil utility. <serviceBehaviors> <behavior name="behaviorConfiguration"> <serviceMetadata httpsGetEnabled="true" /> </behavior> </serviceBehaviors>
WCF Service -Authentication
The wsHttpBinding is configured to use Windows Authentication and transport security. wsHttpBinding by default supports Windows Authentication. <security mode="Transport"> <transport clientCredentialType="Windows" />
WCF Service - Caller Identity
Service retrieves the identity of the caller from the operationcontext for auditing purposes. Use the identity to improve logging and auditing. string identity = OperationContext.Current.IncomingMessageHeaders.GetHeader<string>("identity", "ns");
WCF Service - SQL
The connection string for database is configured to use Windows Authentication. The database connection string includes Integrated Security=SSPI or Trusted Connection=Yes. SqlConnection sqlcon = new SqlConnection("Server=10.3.19.11;Database=Northwind;IntegratedSecurity=SSPI");
Database connection is opened using the WCF process identity’s security context. Service does not impersonate the original caller so SQL Server benefits from connection pooling.

Database Server

Check & More Info Example
WCF Service - Configuration
A SQL Server login is created for the WCF’s service account (process identity). This grants access to the SQL Server. exec sp_grantlogin 'Custom Service Account'
The login is mapped to a database user for the Web application. This grants access to the specified database. use targetDatabase go exec sp_grantdbaccess ' Custom Service Account' go
A database role is created in the target database. This allows access control and authorization to the DB. use targetDatabase go exec sp_addrole 'DB Role Name' go
The login is added to the database role. Grant minimum permissions. For example, grant execute permissions to selected stored procedures and provide no direct table access. use targetDatabase go exec sp_addrolemember 'DB Role Name', 'Custom Service Account' go
WCF Service - Authentication
SQL Server is configured to use Windows authentication.

Communication Security

What Check
Browser to Web Server SSL is used between browser and Web server to protect sensitive data on the wire. Install certificate in the Website. Configure the virtual directory of the Web application to use SSL.
App Server to Database You can use IPSec or SSL between App server and database server to protect sensitive data on the wire.

Analysis

Web Server

Authentication

  • To prevent unauthenticated and unauthorized users from accessing pages, anonymous access is disabled in IIS.
  • Integrated Windows authentication is a good choice for this scenario because all users have Windows accounts. One benefit of integrated Windows authentication is preventing the user's password from ever being sent over the network. Additionally, the logon is transparent for the user because Windows uses the current user's logon session.

Authorization

  • URL authorization is used to perform role checks against the original caller, and to restrict access to pages or folders based on role permissions.
  • All authorization checks are performed in the Web application before calls are made to the WCF Service. The WCF Service trusts the Web application to perform this authorization and does not need to make fine-grained authorization decisions of its own.
  • The Roles Manager is a good choice for this scenario because it allows your ASP.NET code to look up users' roles without writing and maintaining custom code.

WCF Proxy

  • Because all authentication and authorization is handled in the ASP.NET application, calls into the WCF Service use the ASP.NET process identity’s security context. You don’t need to flow the original caller into the WCF Service.
  • If you need to produce audit logs showing what service operations were called by each user, you can pass the identity of the original caller in a custom header.

Configuration

  • In order to reduce attack surface and minimize the impact of a compromise, the ASP.NET application on the Web Server runs under the security context of a Service account using least privilages.
  • Because HTTPS trusts chain validation, the root certificate authority that issued the certificate for WCF transport security needs to be installed in the trusted root certification authorities store of the local machine in the application server. In a production environment, this is not necessary as the certificate will be issued by a known issuer such as Verisign.

Application Server

Authentication

  • In order to authenticate the ASP.NET service when it makes calls on the WCF Service, WCF is configured to use Windows authentication.

Authorization

  • Since the WCF Service trusts the ASP.NET application to authorize the user, the WCF Service performs no authorization.

SQL

  • To reduce the risk of database credentials theft, the database connection string is configured to use Windows authentication. This choice avoids storing credentials in files and passing credentials over the network to the database server.
  • The WCF Service accesses the database using the WCF process identity. As a result, all calls use the single process account and designated database connection pooling.

Configuration

  • This scenario is optimized around interoperability and the ability to host the service in IIS at the expense of transmission performance. For this reason the best binding choice is wsHttpBinding. By default wsHttpBinding supports Windows authentication with message security.
  • Since wsHttpBinding is supported by IIS 6.0, the WCF Service is hosted in IIS.
  • In order to reduce attack surface and minimize the impact of a compromise, the WCF Service is running under the security context of a Service account using least privileges.
  • A metadata exchange (mex) endpoint is exposed with mexHttpsBinding to make it possible for the client to generate a proxy based on the service definition.
  • Because HTTPS trusts chain validation, the root certificate authority that issued the certificate for WCF transport security needs to be installed in the trusted root certification authorities store of the local machine in the application server. In a production environment, this is not necessary as the certificate will be issued by a known issuer such as Verisign.

Database Server

SQL Server database user roles are preferred to SQL Server application roles to avoid the various password management and connection pooling issues associated with the use of SQL application roles. Applications activate SQL application roles by calling a built-in stored procedure with a role name and a password. Therefore, the password must be stored securely. Moreover, using SQL application roles forces you to disable database connection pooling, which severely impacts application scalability.

Creating a new user-defined database role and adding the database user to the role allows you to give specific minimum permissions to the role. In this way, if the database account changes you don't have to change the permissions on all database objects.

Communication Security

  • Use SSL between the browser and Web Server to protect sensitive data on the wire.
  • Use Transport security to protect sensitive data between the Web Server and App Server.
  • You can use IPSec or SSL between the App Server and Database Server to protect sensitive data on the wire.

Example

Domain Controller

Configuration

A Service Principle Name (SPN) is created based on these rules:
  • If the ASP.NET application runs in an application pool with a custom domain identity, create an SPN, and map the custom domain identity with the HTTP service class and both the DNS machine name and the NETBIOS machine name:
setspn -a HTTP//WebServer.domain.com customDomainAccount
setspn -a HTTP//WebServer customDomainAccount
  • If the WCF application runs in an application pool with a custom domain identity, create an SPN and map the custom domain identity with the HTTP service class and both the DNS machine name and the NETBIOS machine name:
setspn -a HTTP//WCFServer.domain.com customDomainAccount
setspn -a HTTP//WCFServer customDomainAccount

Web Server

Code

  • Role-authorization occurs before WCF Service invocation.
  • Identity of the original caller is retrieved from the HttpContext.
  • Message Header containing the caller identity is created and passed to the operation context for auditing purposes.

using System.Security.Principal;
using System.ServiceModel;
using System.ServiceModel.Channels;
…
protected void Button1_Click(object sender, EventArgs e)
 {
     if (Roles.IsUserInRole(@"npscode\Accounting"))
     {
        WCFTestclient.MyServiceClient proxy = new WCFTestclient.MyServiceClient();
        using ( OperationContextScope scope = new OperationContextScope(proxy.InnerChannel))
        {
          string identity = ((WindowsIdentity)HttpContext.Current.User.Identity).Name;
          MessageHeader<string> headerIdentity = new MessageHeader<string>(identity);
          MessageHeader untypedMessageHeader = headerIdentity.GetUntypedHeader("identity", "ns");
          OperationContext.Current.OutgoingMessageHeaders.Add(untypedMessageHeader);
          proxy.GetData("data");          
        }
        proxy.Close();
     }
 }

Configuration

  • Windows authentication is enabled.
  • URL authorization role check is enabled.
  • Role Manager is enabled.

<system.web>
   <assemblies>
     <add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
     <add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
     <add assembly="System.Data.DataSetExtensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
     <add assembly="System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
   </assemblies>

   <authentication mode="Windows" />
      <authorization>
        <allow roles="npscode\BusinessDivision" />
        <deny users="*" />
      </authorization>

      <roleManager enabled="true"
             defaultProvider= "AspNetWindowsTokenRoleProvider"/>

      <pages>
        <controls>
          <add tagPrefix="asp" namespace="System.Web.UI" 
               assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>

          <add tagPrefix="asp" namespace="System.Web.UI.WebControls" 
               assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>

        </controls>
      </pages>

   <httpHandlers>
      <remove verb="*" path="*.asmx"/>
      <add verb="*" path="*.asmx" validate="false" type=
"System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>

      <add verb="*" path="*_AppService.axd" validate="false" type=
"System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>

      <add verb="GET,HEAD" path="ScriptResource.axd" validate="false" type=
"System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>

   </httpHandlers>

   <httpModules>
      <add name="ScriptModule" type=
"System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
   </httpModules>

</system.web>

Application Server

Code

  • The service retrieves the identity of the caller from the operation context if it is required for auditing purposes.
  • The service calls SQL using the security context of the WCF Service.
using System.Data.SqlClient;
public string GetData(string myValue)
{
 SqlConnection sqlcon = new  
  SqlConnection("Server=SqlServer;Database=testdb;Integrated Security=SSPI");
 
 sqlcon.Open();

 //do the business operation	

 string identity = OperationContext.Current.IncomingMessageHeaders.GetHeader<string>("identity", "ns");
    
 return “some data” ;
}

Configuration

  • The service has a binding endpoint that uses wsHttpbinding with a binding configuration to use Windows authentication and transport security.
  • The service has a service behavior configuration to publish metadata.
  • The service behavior is configured with element serviceMedata to allow metadata exposure.
<system.serviceModel>
  <bindings>
    <wsHttpBinding>
      <binding name="httpsendpointconfig">
        <security mode="Transport">
          <transport clientCredentialType="Windows" />
        </security>
      </binding>
    </wsHttpBinding>
  </bindings>
  
  <client/>
  <services>
     <service behaviorConfiguration="behaviorConfiguration" 
              name="MyService">
 
        <endpoint binding="wsHttpBinding" 
                  bindingConfiguration="httpsendpointconfig" 
                  name="httpsendpoint" 
                  contract="IMyService2"/>
     </service>
  </services>

  <behaviors>
     <serviceBehaviors>
       <behavior name="behaviorConfiguration">
          <serviceMetadata httpsGetEnabled="true" />
       </behavior>
     </serviceBehaviors>
  </behaviors>

</system.serviceModel>

Database Server

Configuration

  • A SQL server login is created for the WCF Service account.
  • The WCF login name is given access to the database.
  • The role is created in the database.
  • The WCF login name is added to the role.
-- Create a SQL Server login  that matches the WCF machine name
_EXEC SP_GRANTLOGIN 'npscode\perfpres02$'_

-- Grant the login access to the application database
_use testdb_ 
_go_ 
_exec sp_grantdbaccess 'npscode\perfpres02$'_ 

-- Create the new database role
use testdb
go
exec sp_addrole 'myrole2','db_owner' 

-- Add the new login to the role
use testdb
go
exec sp_addrolemember 'myrole2','npscode\aspnethost' 

Additional Resources

  • For more information on WCF Transport Layer Security using wsHttpBinding and SSL, see How To: Use wsHttpBinding with Windows Authentication and Transport Security in WCF Calling from Windows Forms
  • For more information on how to work with temporary certificates, see “How to: Create Temporary Certificates for Use During Development” at http://msdn2.microsoft.com/en-us/library/ms733813.aspx
  • For more information on how to view certificates by using the Microsoft Management Console (MMC) snap in, see “How to: View Certificates with the MMC Snap-in” at http://msdn2.microsoft.com/en-us/library/ms788967.aspx
  • For more information on differences in certificate validation between Microsoft Internet Explorer and WCF, see “Differences Between Service Certificate Validation Done by Internet Explorer and WCF” at http://msdn2.microsoft.com/en-us/library/aa702599.aspx
  • For more information on differences in certificate validation between protocols, see “Certificate Validation Differences Between HTTPS, SSL over TCP, and SOAP Security” at http://msdn2.microsoft.com/en-us/library/aa702579.aspx



Last edited Jun 26, 2008 at 11:44 PM by rboucher, version 41

Comments

No comments yet.