PII Security Lockdown
This sample demonstrates how to control several security-related features of a Windows Communication Foundation (WCF) service by:
Encrypting sensitive information in a service's configuration file.
Locking elements in the configuration file so that nested service subdirectories cannot override settings.
Controlling the logging of Personally Identifiable Information (PII) in trace and message logs.
Each of these features can be used separately or together to control aspects of a service's security. This is not a definitive guide to securing a WCF service.
The .NET Framework configuration files can contain sensitive information such as connection strings to connect to databases. In shared, Web-hosted scenarios it may be desirable to encrypt this information in the configuration file for a service so that the data contained within the configuration file is resistant to casual viewing. .NET Framework 2.0 and later has the ability to encrypt portions of the configuration file using the Windows Data Protection application programming interface (DPAPI) or the RSA Cryptographic provider. The aspnet_regiis.exe using the DPAPI or RSA can encrypt select portions of a configuration file.
In Web-hosted scenarios it is possible to have services in subdirectories of other services. The default semantic for determining configuration values allows configuration files in the nested directories to override the configuration values in the parent directory. In certain situations this may be undesirable for a variety of reasons. WCF service configuration supports the locking of configuration values so that nested configuration generates exceptions when a nested service is run using overridden configuration values.
This sample demonstrates how to control the logging of known Personally Identifiable Information (PII) in trace and message logs, such as username and password. By default, logging of known PII is disabled however in certain situations logging of PII can be important in debugging an application. This sample is based on the Getting Started Sample. In addition, this sample uses tracing and message logging. For more information, see the Tracing and Message Logging sample.
Encrypting configuration file elements
For security purposes in a shared Web-hosting environment, it may be desirable to encrypt certain configuration elements, such as database connection strings that may contain sensitive information. A configuration element may be encrypted using the aspnet_regiis.exe tool found in the .NET Framework folder For example, %WINDIR%\Micrsoft.NET\Framework\v2.0.50727.
To encrypt the values in the appSettings section in Web.config for the sample
Open a command prompt by using Start->Run…. Type in cmd and click OK.
Navigate to the current .NET Framework directory by issuing the following command:
cd %WINDIR%\Micrsoft.NET\Framework\v2.0.50727.Encrypt the appSettings configuration settings in the Web.config folder by issuing the following command:
aspnet_regiis -pe "appSettings" -app "/servicemodelsamples" -prov "DataProtectionConfigurationProvider".
More information about encrypting sections of configuration files can be found by reading a how-to on DPAPI in ASP.NET configuration (Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication) and a how-to on RSA in ASP.NET configuration (How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA).
Locking configuration file elements
In Web-hosted scenarios, it is possible to have services in subdirectories of services. In these situations, configuration values for the service in the subdirectory are calculated by examining values in Machine.config and successively merging with any Web.config files in parent directories moving down the directory tree and finally merging the Web.config file in the directory that contains the service. The default behavior for most configuration elements is to allow configuration files in subdirectories to override the values set in parent directories. In certain situations it may be desirable to prevent configuration files in subdirectories from overriding values set in parent directory configuration.
The .NET Framework provides a way to lock configuration file elements so that configurations that override locked configuration elements throw run-time exceptions.
A configuration element can be locked by specifying the lockItem attribute for a node in the configuration file, for example, to lock the CalculatorServiceBehavior node in the configuration file so that calculator services in nested configuration files cannot change the behavior, the following configuration can be used.
<configuration>
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="CalculatorServiceBehavior" lockItem="true">
<serviceMetadata httpGetEnabled="True"/>
<serviceDebug includeExceptionDetailInFaults="False" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
Locking of configuration elements can be more granular. A list of elements can be specified as the value to the lockElements to lock a set of elements within a collection of sub-elements. A list of attributes can be specified as the value to the lockAttributes to lock a set of attributes within an element. An entire collection of elements or attributes can be locked except for a specified list by specifying the lockAllElementsExcept or lockAllAttributesExcept attributes on a node.
PII Logging Configuration
Logging of PII is controlled by two switches: a machine-wide setting found in Machine.config that allows a machine administrator to permit or deny logging of PII and an application setting that allows an application administrator to toggle logging of PII for each source in a Web.config or App.config file.
The machine-wide setting is controlled by setting enableLoggingKnownPii to true or false, in the machineSettings element in Machine.config. For example, the following allows applications to turn on logging of PII.
<configuration>
<system.serviceModel>
<machineSettings enableLoggingKnownPii="true" />
</system.serviceModel>
</configuration>
Note
The Machine.config file has a default location: %WINDIR%\Microsoft.NET\Framework\v2.0.50727\CONFIG.
If the enableLoggingKnownPii attribute is not present in Machine.config, logging of PII is not allowed.
Enabling logging of PII for an application is done by setting the logKnownPii attribute of the source element to true or false in the Web.config or App.config file. For example, the following enables logging of PII for both message logging and trace logging.
<configuration>
<system.diagnostics>
<sources>
<source name="System.ServiceModel.MessageLogging" logKnownPii="true">
<listeners>
...
</listeners>
</source>
<source name="System.ServiceModel" switchValue="Verbose, ActivityTracing">
<listeners>
...
</listeners>
</source>
</sources>
</system.diagnostics>
</configuration>
If the logKnownPii attribute is not specified, then PII is not logged.
PII is only logged if both enableLoggingKnownPii is set to true, and logKnownPii is set to true.
Note
System.Diagnostics ignores all attributes on all sources except the first one listed in the configuration file. Adding the logKnownPii attribute to the second source in the configuration file has no effect.
Note
To run this sample involves manual modification of Machine.config. Care should be taken when modifying Machine.config as incorrect values or syntax may prevent all .NET Framework applications from running.
It is also possible to encrypt configuration file elements using DPAPI and RSA. For more information, see the following links:
Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication
How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA
To set up, build and run the sample
Ensure that you have performed the One-Time Set Up Procedure for the Windows Communication Foundation Samples.
Edit Machine.config to set the enableLoggingKnownPii attribute to true, adding the parent nodes if necessary.
To build the C# or Visual Basic .NET edition of the solution, follow the instructions in Building the Windows Communication Foundation Samples.
To run the sample in a single- or cross-machine configuration, follow the instructions in Running the Windows Communication Foundation Samples.
To clean up the sample
- Edit Machine.config to set the enableLoggingKnownPii attribute to false.
© 2007 Microsoft Corporation. All rights reserved.