Intranet - Web App to Local WCF to SQL Server - Original Caller

In this scenario, a Web server that runs ASP.NET pages connects to a WCF service on a remote server. This server in turn connects to a remote database server. The application relies on the WCF service for data retrieval. The basic model for this application scenario is shown in the following figure.

scenario1.gif

Key Characteristics

  • Users have browsers supporting Integrated Windows Authentication.
  • User accounts are in Active Directory within a single forest.
  • User roles are windows groups.
  • The application needs to flow the original caller security context to authorize user at application level (WCF).
  • Optionally application can impersonate user at application level (WCF).
  • All tiers should use Windows authentication.

Solution – Web to Application to Database

solution2.gif

Solution Summary Table

Web Server

What Checks Example More Info
IIS
Configuration A dedicated application pool is used and configured to run under a custom service account. ServiceAccount1 In developer environment use Network Service account and in production environment use custom domain service account.
The web application is configured to run under the service account. Assign the web application to the custom application pool.
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 <authentication mode = "Windows" > The web application will authenticate the users.
Authorization If you have role segmentation in your application then you use URL authorization. The authorized users have access to specific pages
If required, Role-checks (user's Windows group membership) are performed by using role manager APIs with WindowsTokenRoleProvider
Configuration ASP.NET has a proxy reference to the WCF service. The application has access to the WCF metadata to create a service reference.
Impersonation / Delegation ASP.NET Impersonates the original callers <identity impersonate="true"/> This allows to flow the original user identity to WCF service for downstream authorization
WCF Proxy
Proxy invokes services with the security context of caller without passing credentials A proxy will invoke a WCF method within the service contained on the application server using the original user’s security context.

Application Server

What Checks Example More Info
IIS
Configuration A dedicated application pool is used and configured to run under a custom service account. ServiceAccount1 In developer environment use Network Service account, in production environment use a custom domain service account.
The WCF service is configured to run under a service account. Assign the WCF service to the custom application pool.
Authentication The IIS virtual directory is configured to use Windows Integrated Authentication. IIS validates the user accounts using Windows authentication.
Anonymous access is disabled.
WCF Service
Authentication The WCF service is configured to authenticate clients with Windows credentials. <transport clientCredentialType="Windows" /> Basic Http binding with transport credential only mode and windows credentials.
Authorization The service is configured with a service behavior to authorize users with UseWindowsGroups. <serviceAuthorization principalPermissionMode="UseWindowsGroups" ... /> Roles authorization can be performed declaratively or imperatively in the operation contract
Perform Role-checks declaratively using Windows Identity Token, for checking Active Directory group membership. [PrincipalPermission(SecurityAction.Demand, Role = "Builtin\\Administrators")]
Perform Role-checks imperatively using Windows Identity Token, for checking Active Directory group membership new PrincipalPermission(id2, "Supervisor").Demand();
Configuration Configure the WCF service to use Basic Http binding <endpoint binding="basicHttpBinding" … /> This is required when you need to pass credentials and not be forced to use SSL.
The connection string for database is configured to use windows authentication The database connection string includes Integrated Security=SSPI or Trusted Connection=Yes Use the WCF / ASP.NET process identity for accessing database
Encrypt the connection string section Using a protected configuration provider (DPAPI on a single machine, RSA if in a Web farm). Tradeoff here is added deployment complexity vs. keeping the database name and location a secret
Impersonation If required to access system resources on original callers behalf, impersonate the original caller at service level <serviceAuthorization impersonateCallerForAllOperations="true" /> This will impersonate original caller when calling any of the methods exposed by the WCF service, you can set it in Web.config file of the WCF service.
If required to access system resources on original callers behalf, impersonate the original caller at method level [OperationBehavior(Impersonation = ImpersonationOption.Required)] This will impersonate original caller when calling specific methods, it is set on the individual WCF service methods.
If required to access system resources on original callers behalf, impersonate the original caller programmatically using (callerWindowsIdentity.Impersonate()) This will impersonate original caller for required code sections only, gives greater control on impersonating.

Database Server

What Check Example More Info
Configuration A SQL Server login is created for the WCF’s service account (process identity).
The login is mapped to a database user for the Web application.
Authentication SQL Server is configured to use Windows authentication.
Authorization The database user is placed in a database role for the WCF service. SQL Server authorizes the role rather than the user login.
Database permissions are granted to the database role. Only grants execute permissions on necessary stored procedures.

Communication Security

What Check Example More Info
Browser to Web Server SSL is used between browser and Web server to protect sensitive data on the wire.
Web Server to App Server To protect sensitive data, if using transport layer security – use SSL
To protect sensitive data, if using message level security – encrypt and sign messages using windows token
App server to Database IPSec or SSL can be used between App server and database server to protect sensitive data on the wire.

Analysis

Authentication

  • On the Web Server the Integrated Windows authentication is used in IIS, because all users have Windows accounts. The benefit of Integrated Windows authentication is that the user's password is never sent over the network. Additionally, the logon is transparent for the user because Windows uses the current interactive user's logon session.
  • In the ASP.NET application on the web server impersonate the original callers, to access WCF and pass the original user identity downstream.
  • On the Application Server, WCF uses Windows Integrated authentication because all users have Windows accounts, allowing for authorization with windows users and groups. Additionally if message security is required the windows token can be used to encrypt and sign the message.
  • Per user authentication is used for accessing WCF, so if required to roles based authorization can be done or the original callers can be impersonated for resource based authorization.
  • Using Windows authentication to SQL Server means that you avoid storing credentials in files and passing credentials over the network to the database server.

Authorization

  • In the ASP.NET application on the Web server, the Url authorization is used to performs role checks against the original caller to restrict access to pages.
  • In the ASP.NET application on Web Server, role based authorization on the original caller's Windows group membership is done to control access to the WCF service methods.
  • In WCF Service on Application Server .NET roles are used to authorize the users based on the Windows group to which they belong.
  • The WCF service does not impersonate by default – if you need to impersonate you can impersonate at the service level, method level or impersonate programmatically, this is required if you have to control access to downstream resources on per user basis. If using impersonation resources accessed by the WCF service must be configured with an ACL that grants at least read access to the original caller.
  • If the WCF service does not impersonate, then it accesses local system resources and the database using the ASP.NET process identity. As a result, all calls are made using the single process account. This enables database connection pooling to be used.

Administration

  • The ASP.NET application on the Web Server is running under the security context of the Service account which is a least privileged local / domain account, so potential damage from compromise is mitigated.
  • If sensitive data is being passed between the browser and the web server, consider using SSL which will protect the data.
  • The WCF service on the Application server is running under the security context of the service account which is a least privileged local / domain account, so potential damage from compromise is mitigated.
  • If Web server and App server are in trusted environment and you don’t need transport level security – you need to use basic http binding.
  • If the Web Server and WCF service exchange sensitive data which needs to be protected – use transport layer security, which needs to use SSL or use message level security where the messages are encrypted and signed using the windows token.
  • SQL Server database user roles are preferred to SQL server application roles to avoid the associated password management and connection pooling issues associated with the use of SQL application roles.
  • The database user is added to a database user role and permissions are assigned for the role so that if the database account changes; you don't have to change the permissions on all database objects.
  • If the sensitive data exchanged between the WCF service and the database is to be protected consider using IPSec / SSL.

ASP.NET Compatibility

WCF service hosted in IIS can run with ASP.NET compatible mode. For this to happen a entry in configuration file needs to be included and an attribute at a service level also needs to be used
  • Configuration entry
<system.serviceModel>
  <serviceHostingEnvironment aspNetCompatibilityEnabled="false"/>
</system.serviceModel>
  • Attribute of service contract
[ServiceBehavior]
[AspNetCompatibilityRequirements(RequirementsMode=AspNetCompatibilityRequirementsMode.Allowed)]
class BarService : IHelloContract
{
    // ...
}

  • Using asp.net compatible mode provides the following benefits:
    • ASP.net impersonation if WCF impersonation is not enabled. If WCF impersonation is enabled it prevails over ASP.net impersonation.
    • ASP.net session state, which provides with a shared state mechanism, surviving app domain recycles and support in web farms environments.
    • File URL authorization in ASP.net.
    • HTTPcurrent. Context features also present in OperationContext.Current WCF counterpart.
    • Globalization and configuration in ASP.net
    • Support for cookies with HttpTransportBindingElement.AllowCookies binding configuration.

Impersonation

  • On the Web Server ASP.NET needs impersonate the client to flow the identity to WCF
  • Impersonating the callers in asp.net impacts scalability of the application at the web server layer.
  • Using the .net service account in the application layer in a web farm configuration when negotiate service credentials is false may cause authentication failures. Consider using a domain account and set the service principal name to the domain account.
  • You have three options for impersonation
    • Service Level
    • Method Level
    • Programmatic
  • Impersonating the calls can pose a security risk, when impersonation is configured in WCF service. The client can control the impersonation regardless of impersonation configuration of the service. Consider restricting impersonation of calls, via proxy invocation, when restriction of impersonation is needed.
proxy.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.None;
proxy.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Anonymous

Service Level

  • Impersonating at service level may have security implications with elevation of privileges in more than needed scope. Consider more granular scope where programmatic impersonation is possible.
  • Impersonation can be configured at service level.
<serviceBehaviors>
  <behavior name="ImpersonationandMetadata">
    <serviceMetadata httpGetEnabled="true" />
    <serviceAuthorization impersonateCallerForAllOperations="true" />
  </behavior>
</serviceBehaviors>

Method Level

  • Impersonating at method or operation level may have security implications with elevation of privileges in more than needed scope. Consider more granular scope where programmatic impersonation is possible.
  • Impersonation can happen at operation contract level.
[OperationBehavior(Impersonation = ImpersonationOption.Required)]
public string Hello(string message)
{
    return "hello";
}

Programmatic

  • Impersonation can be done programmatically.
...
using (callerWindowsIdentity.Impersonate())
{
    // Access a resource as the original caller.
}
...

Authorization

  • The service is configured with a service behavior to authorize users with UseWindowsGroups.
  • Perform Role-checks declaratively using Windows Identity Token, for checking Active Directory group membership.
[PrincipalPermission(SecurityAction.Demand, 
                     Role = "Builtin\\Administrators")]
public string Hello(string message)
{
    return "hello";
}
  • Perform Role-checks imperatively using Permission demands
String role2 = "Supervisor";
PrincipalPermission PrincipalPerm2 = 
    new PrincipalPermission(id2, role2);
PrincipalPerm2.Demand();

Service Accounts

When deciding on the Service accounts to be used, you need to consider whether it’s a development or production scenario. For development scenario you need to use the easier method to avoid the overheads, but with production scenario you need to ensure its secure and practical in production environment.

Development Scenario

  • Local network service accounts can be used on both Web and WCF servers. The network service account is identified as machine account in the domain and hence can be used to windows authentication.

Production Scenario

  • Create a custom domain service accounts with least privilege. For more information see “How To: Create a Service Account for an ASP.NET 2.0 Application” at http://msdn2.microsoft.com/en-us/library/ms998297.aspx
  • The same domain account can be used both at Web and WCF servers. If a domain account is used then is necessary to create service principal name attached to the domain account for Kerberos to work.
setspn -a http/perfapp01.npscode.com npscode\aspnethost
  • In web farms configurations a domain account must be used, instead of local network service account. Additionally a SPN identity must be configured in the endpoint configuration for clients to be able to authenticate the service
<identity>
          <servicePrincipalName value=" HOST/perfapp01.npscode.com.com" />
</identity>

Auditing and Logging

  • Auditing for authorization and authentication in WCF can be configured via service behavior. Configure the service behavior as follows:
<serviceSecurityAudit serviceAuthorizationAuditLevel="Failure"
messageAuthenticationAuditLevel="Failure" />
  • Logging can be configured to log messages at transport or message level
<system.diagnostics>
 <sources>
   <source name="System.ServiceModel" switchValue="Off,ActivityTracing"
     propagateActivity="true">
     <listeners>
       <add type="System.Diagnostics.DefaultTraceListener" name="Default">
         <filter type="" />
       </add>
       <add name="ServiceModelTraceListener">
         <filter type="" />
       </add>
     </listeners>
   </source>
   <source name="System.ServiceModel.MessageLogging" switchValue="Warning, ActivityTracing">
     <listeners>
       <add type="System.Diagnostics.DefaultTraceListener" name="Default">
         <filter type="" />
       </add>
       <add name="ServiceModelMessageLoggingListener">
         <filter type="" />
       </add>
     </listeners>
   </source>
 </sources>
 <sharedListeners>
   <add initializeData="c:\pag\wcfservice1\web_tracelog2.svclog"
     type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
     name="ServiceModelTraceListener" traceOutputOptions="Timestamp">
     <filter type="" />
   </add>
   <add initializeData="c:\pag\wcfservice1\web_messages4.svclog"
     type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
     name="ServiceModelMessageLoggingListener" traceOutputOptions="DateTime, Timestamp, ProcessId, ThreadId">
     <filter type="" />
   </add>
 </sharedListeners>
 <trace autoflush="true" />
</system.diagnostics>

Last edited Jan 26, 2008 at 12:06 AM by prashantbansode, version 3

Comments

No comments yet.