.NET 2.0: On-demand Configuration Encryption

October 2nd, 2006 Comments
Binary Code

In .NET 2.0, apsnet_regiis can encrypt and decrypt sections of web.config and machine.config using RSA, DPAPI, or any other custom encryption provider. However, how do we encrypt/decrypt a custom application configuration (e.g. app.config of a WinForms application)?

We are in luck, since the System.Configuration namespace provides everything we need to accomplish this task. The following class, for example, can be used to encrypt/decrypt any .NET configuration file:

///
/// Implements a utility class that enables encrypting / decrypting
/// sections in .NET configuration files.
///
internal static class ConfigEncryptionHelper
{
    #region Encryption Methods

    ///
    /// Encrypts a section in a .NET configuration file using a named provider.
    ///
    /// Physical path of configuration file.
    /// Section name to encrypt.
    /// Name of the encryption provider.
    public static void EncryptConfigSection(string configPath, string sectionName, string protectionProviderName)
    {
        // Map the configuration file
        ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
        fileMap.ExeConfigFilename = configPath;

        // Open configuration file
        Configuration config = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);

        // Get the desired section
        ConfigurationSection section = config.GetSection(sectionName);

        // Encrypt the section
        if (!section.SectionInformation.IsProtected)
            section.SectionInformation.ProtectSection(protectionProviderName);

        // Save configuration file
        config.Save();
    }

    ///
    /// Encrypts a section in a .NET configuration file using DataProtectionProvider.
    ///
    /// Physical path of configuration file.
    /// Section name to encrypt.
    public static void EncryptConfigSection(string configPath, string sectionName)
    {
        EncryptConfigSection(configPath, sectionName, "DataProtectionConfigurationProvider");
    }

    #endregion

    #region Decryption Methods

    ///
    /// Decrypts a section in a .NET configuration file.
    ///
    /// Physical path of configuration file.
    /// Section name to encrypt.
    public static void DecryptConfigSection(string configPath, string sectionName)
    {
        // Map the configuration file
        ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
        fileMap.ExeConfigFilename = configPath;

        // Open configuration file
        Configuration config = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);

        // Get the desired section
        ConfigurationSection section = config.GetSection(sectionName);

        // Decrypt section
        if (section.SectionInformation.IsProtected)
            section.SectionInformation.UnprotectSection();

        // Save configuration file
        config.Save();

    }

    #endregion
}

Securing ASP.NET 2.0 Apps Using Membership and Role Providers

August 17th, 2006 Comments

I recently designed an intranet application using ASP.NET 2.0 and really loved the membership and role providers that tremendously simplifified our implementation of security features in the application. Membership and role information can be stored in a SQL Server database or another repository such as Active Directory. For our intranet application it made sense to use Active Directory as the membership provider and SQL Server as the role provider.

Configuring Role and Membership Providers:

Essentially everything is configured declaritively using Web.config:

In the above configuration file, note that we first specify our connection strings starting at line 2. LocalSqlServer points to a SQL Server database which has been configured using aspnet_regsql. The second connection string points to the domain controller for membership authentication.

In the authentication section we specify that we are using forms authentication, and provide the URL for our logon page.

In the roleManager section we configure our role provider, pointing back to LocalSqlServer as the role repository.

In the membership section we configure our membership provider pointing back to ADConnectionString (domain controller) specified in the connectionStrings section.

Finally we restrict users from accessing certain folders based on their roles using location sections (role-based security).