IIS and .NET Framework Security

Article
06/17/2011

Windows Server AppFabric uses the robust security features of IIS and the .NET Framework version 4 to secure the .NET Framework 4 services hosted in Windows Process Activation service (WAS). To help you understand how to correctly configure client-to-service security within AppFabric, it is important to understand the security options within IIS and the .NET Framework.

In general, there are many layers of security options available, and you should utilize the ones most appropriate to your deployment. Each security layer provides the ability to secure specific resources. For example, tooling within IIS generally provides the means of securing IIS artifacts such as sites and applications, while .NET Framework 4 security settings can be applied to WCF/WF service concepts such as services, endpoints, and operations.

For more information about security, see Windows Communication Foundation Security (https://go.microsoft.com/fwlink/?LinkId=183157) and IIS Security (https://go.microsoft.com/fwlink/?LinkId=183159).

IIS Security and AppFabric

IIS affects security for an application from the calling client side and also when the .NET Framework service accesses the monitoring and persistence data stores. IIS affects AppFabric security in the following areas:

IIS_IUSRS. The Windows security group used to manage run-time access to files and folders in the default IIS installation.

Security Note

Do not confuse the Windows security group IIS_IUSRS with the SQL Server login name IIS_IUSRS. They are related yet separate entities.
Application pool identity. IIS dynamically inserts all application pool identities into the IIS_IUSRS group at run time. This security group is granted permission to access the necessary data stores, particularly the persistence data store. For more information, see SQL Server Security.

Security Note
Do not confuse the Windows security group IIS_IUSRS with the SQL Server login name IIS_IUSRS. They are related yet separate entities.

.NET Framework Security for AppFabric

When we discuss security for .NET Framework services configured in AppFabric, we are really referring to WCF. WCF defines the transport protocol used to communicate between a WCF client and a .NET Framework (WCF or WF) service. It is the part of the .NET Framework that provides a unified programming model for rapidly building service-oriented applications that communicate across the Web and the enterprise. WCF not only integrates with existing security infrastructures, but also extends distributed security beyond Windows-only domains by using secure SOAP messages. For more information see Windows Communication Foundation Security (https://go.microsoft.com/fwlink/?LinkId=183157) and Security Architecture (https://go.microsoft.com/fwlink/?LinkId=183160).

Combining IIS and .NET Framework Security

It is critical to the integrity of an application to ensure that a message sent to a service is not viewed or modified during the transfer process. You can do this by using encryption and signing. But message transfer is only truly secure if you can also validate, or authenticate, with complete certainty the identity of the calling client application. With AppFabric, it is important to understand how IIS and WCF work together to ensure that this occurs.

For more information about patterns and practices surrounding Web services security, see Patterns & Practices: Improving Web Services Security Guide (https://go.microsoft.com/fwlink/?LinkId=183161).

IIS Authentication in AppFabric

WCF transport security mechanisms in Windows depend on the binding and subsequent transport being used. For example, when using the WSHttpBinding class, the transport is HTTP, and the primary mechanism for securing the transport is Secure Sockets Layer (SSL) over HTTP, commonly recognized as HTTPS. Message security uses the WS-Security specification to secure messages at the message level. It entails enhancements to SOAP messaging to ensure confidentiality, integrity, and authentication at the SOAP message level (instead of at the transport level).

Hosted Service Modes

Hosted services can run in two modes: Mixed Transports Mode or ASP.NET Compatibility Mode. The mode is controlled by the application-level configuration flag aspNetCompatibilityEnabled. You can also get this flag at run time from the static property ServiceHostingEnvironment.AspNetCompatibilityEnabled. The aspNetCompatibilityEnabled flag is false by default and thus services run in the Mixed Transports Mode unless you explicitly change this setting.

<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="false"/>
</system.serviceModel>

Mixed Transports Mode

In Mixed Transports Mode, the HTTP module intercepts the request in the early stage of the pipeline: BeginRequest. When the request comes in, the HTTP module sets HttpContext.Current to null and reverts the impersonation if the thread is impersonated. Because the client request is intercepted at this early stage, other HTTP features are disabled automatically. So when running in Mixed Transports Mode services do not have access to the following ASP.NET HTTP-specific features:

HttpContext.Current. This is always null in this mode. WCF provides a counterpart to this feature: OperationContext.Current.
File/URL authorization. This transport layer authorization feature is normally enabled through the <system.web/authorization> section in the Web.config file for ASMX services. Transport authorization is disabled in mixed mode in WCF. Your only option to do file/URL authorization is to use message-level authorization implemented in WCF.
Impersonation. Impersonation allows the service to act as the client while performing an action on the server. The ASP.NET impersonation feature is normally enabled through the <system.web/identity> section in the Web.config file for ASMX services. It is not available in the WCF transport layer in mixed mode.
Session state. The ASP.NET session state is not supported in mixed mode. WCF has its own reliable session implementation that provides flexible session state management. The biggest problem for WCF is that the session state does not survive on application recycling and does not work in Web gardens or Web farms. This is because there is no mechanism to share state between applications or processes, unlike the (disabled) ASP.NET state service.
Other HTTP features. Other HTTP features rely on HttpContext.Current and are not supported in the mixed mode. For example, you cannot expect to receive the correct result from ConfigurationManager.AppSettings. The globalization feature through <system.web/globalization> is not available.

IIS authentication is ignored in WCF calls into .NET Framework services when running in Mixed Transports Mode. This leaves WCF security as the primary mechanism to authenticate and secure the message transfer between the WCF client and the .NET Framework service. In Mixed Transports Mode, all transports are treated the same. A service can have multiple WCF endpoints and they can listen on the same or different transports such as HTTP, net.tcp, net.pipe, net.msmq, etc. However, hosted services running in Mixed Transports Mode still rely on ASP.NET and IIS to provide the hosting environment, application configuration, and deployment.

ASP.NET Compatibility Mode

To use IIS authentication in any WAS-hosted application, including of course any application hosted in AppFabric, you need to use ASP Compatibility Mode and WCF Transport security. You can take advantage of the following IIS security features only by using ASP Compatibility Mode:

Control which Windows users, and members of which Windows groups, are allowed to connect to a site or an application hosting services using IIS Manager.
Convert a Web site into an IIS virtual directory, and then set security settings to the physical path of the virtual directory in two ways. Pass-through authentication tells IIS to pass on to the Windows file system the credentials of the authenticated user when accessing the physical path of the virtual directory. Alternatively, you can designate a specific user identity for the process hosting your .NET Framework services to access all of the contents in the specified physical path.
Select the appropriate IIS authentication method (Anonymous, Basic, Forms, Digest, Windows Authentication, or ASP.NET forms impersonation) to control security for calls coming into the services associated with the Web site.

You can take advantage of the following IIS security features regardless of whether ASP Compatibility Mode is enabled:

Configure SSL settings to use 64- or 128-bit encryption, and configure how to handle client certificates for incoming requests.
Create authorization rules to allow or deny user access to Web sites or applications.
Use IIS logging capabilities to create a security audit log of incoming requests.
Edit security surrounding connection strings into the monitoring and persistence databases.
Manage binding settings for clients calling into services.
Configure the file-level execution permissions (full control, read and execute, list file contents, write, and so on) on the containing Web site or its contained service applications.
Change the default NetworkService identity of a custom application pool to a specific identity that it can run under. If using integrated security on SQL Server, this is the identity used to make calls into SQL Server.

For more information, see WCF Services and ASP.NET (https://go.microsoft.com/fwlink/?LinkId=183163).

Authentication Guidance

To enable IIS authentication for an application:

Use ASP Compatibility Mode
Use an HTTP-based WCF binding that supports Transport security mode (basicHttpBinding, wsHttpBinding, and wsFederationHttpBinding)

After these requirements are satisfied, configure IIS and the hosted .NET Framework service to use compatible IIS and WCF security settings. Configure the various security settings of the application to match the security and bindings of all its services. Specifying a different scheme will cause a WCF service activation error. Security modes in WCF (in this case, Transport security mode) are specified in the binding elements. They must support authentication, so ensure that the WCF security settings you choose are compatible with the IIS settings. The transport maps to the configured WCF authentication mode for the binding. The service dictates the authentication mode through its binding configuration, and the WCF client must comply with this in its configuration file. The client must be configured to provide the proper form of client credentials to support the authentication scheme provided by the service. Because AppFabric does not provide a UI element to make these types of changes you will have to do this manually in the applicable Web.config file.

Security Note
wsDualHttpBinding supports only Message-based security so you cannot use it if you use IIS authentication in your services.

Share via