The Web Store breaks out into two distinct sections:

• The public facing Web Store interface which is open to all
  
• The admin interface which is restricted
  

Administration Authentication

The public portion of the site is open to all and there are no restrictions. The public portion of the site matches the root directory of the Web store Web root.

The portion Authentication applies to is the /Admin directory which sits below the Web Root. You can use either Windows Authentication or Forms Authentication to protect the Admin directory. The default is Windows Authentication.

Windows Authentication

By default the store installs configured for Windows Authentication which is easiest to use. To make Windows Authentication work all you need to make sure of is that the virtual directory is configured for Windows Authentication. If you set up the Web Store with the _WebStoreConfig.exe utility Windows Authentication is automatically enabled.

Authentication mode is set in web.config:

<authentication mode="Windows">
  <forms loginUrl="admin/AdminLogin.aspx" timeout="20">
    <credentials passwordFormat="Clear">
      <user name="rick" password="secret" />
    </credentials>
  </forms>
</authentication>

The Forms security is not used with Windows Authentication. With Windows Authentication enabled all unauthenticated users are rejected by default. The configuration for access is set in web.config in the specific <location> section for the /Admin directory:

<!-- PROTECT THE ADMIN DIRECTORY -->
<location path="admin">
<system.web>
  <!-- For Windows Authentication Authenticate on Admin 
       so we can elevate the rights of the user to get
       Server information and modify web.config for configuration page.
       
       If you use Windows Authentication make sure that Windows Authentication
       is enabled on the Web Store virtual/application in IIS.
       
       The setting is ignored for Forms Authentication
  -->
  <identity impersonate="true" />
  <authorization>
    <!-- Deny any unauthenticated users -->
    <deny users="?" />
  </authorization>
</system.web>
</location>

If you want enable access only to specific users you can add a specific allow specific users or groups:

<authorization>
   <allow users="rstrahl,megger" roles="Administrators">
   <deny users="*">
</authorization>

Note also that Impersonation is enabled by default. This is done in hopes the account that logs on has rights to write to the Web directory and so can save configuration settings into Web.config.

Impersonation may not be necessary if the Web account can already write into the web directory.

Forms Authentication

You can also switch Authentication to Forms in web.config:

<authentication mode="Forms">
  <forms loginUrl="admin/AdminLogin.aspx" timeout="20">
    <credentials passwordFormat="Clear">
      <user name="rick" password="secret" />
    </credentials>
  </forms>
</authentication>

You can add any credentials you like here by adding user names and passwords that are allowed.

The default settings refuse connection to any non-authenticated users and redirect to the AdminLogin.aspx page if the user is not authenticated.

<!-- PROTECT THE ADMIN DIRECTORY -->
<location path="admin">
<system.web>
  <!-- For Windows Authentication Authenticate on Admin 
       so we can elevate the rights of the user to get
       Server information and modify web.config for configuration page.
       
       If you use Windows Authentication make sure that Windows Authentication
       is enabled on the Web Store virtual/application in IIS.
       
       The setting is ignored for Forms Authentication
  -->
  <identity impersonate="false />
  <authorization>
    <!-- Deny any unauthenticated users -->
    <deny users="?" />
  </authorization>
</system.web>
</location>

Again, you can specify specific user names with:

<authorization>
   <allow users="rick,markus" roles="Admins">
   <deny users="*">
</authorization>

The users and roles should match the entries you created in the <credentials> section above.

MemberShip Services currently are not enabled, primarily because it seems overkill to provide MemberShip only to allow access to the Administration features, which is not likely to be accessible to more than a few people. However you can hook up MemberShip services easily enough on your own if you choose to handle security account storage in a data base.

Web.Config Security

The Web Store configuration settings page writes its configuration settings to the web.config file and so the Web application needs explicit rights to write to the web.config file. There are two ways that this can happen:

• The Application Account has rights to write the file
  
• You use Windows Authentication and use impersonation
  in the <location> section with an account that has write access to web.config
  

The first option assumes that the account that the application runs under has rights to write web.config. The default account is NETWORK SERVICE/ASPNET or the account an ISP or other administrator configures the IIS Application Pool to run under. It's common that this account will have full access to the Web directory. Enabling read/write access on Web.config is required in order to write into web.config. The Web Store configuration does this automatically during local installation, but this may not happen at your ISP.

The other alternative is to configure a <location> for the Admin directory in your web.config file and enable Impersonation in this directory. If you then log on with an account that has sufficient rights to write web.config you can use the Configuration page and persist reliably to web.config. This is likely not an option either if you are with an ISP that doesn't allow for special access.

No Write Access to web.config: Manual web.config Editing
If neither of these options is available web.config cannot be changed through code and so neither App.Configuration.WriteKeysToConfig() or the Save button on the Configuration page will be able to persist settings to web.config automatically. This means you'll have to manually change settings in web.config to make persistant changes.

To do so you need to disable the encryption for various keys of the configuration class - by default these keys are written out in encrypted format, but for manual editing you can't use this encryption. To do disable the encryption open the WebStoreConfig class in the Westwind.WebStore.Business in the \Configuration folder and comment the SetEncryption line:

public WebStoreConfig()
{
    // *** Comment the following line to disable Encryption for manual web.config editing
    // this.SetEncryption("ConnectionString,MailPassword,CCMerchantPassword,WebServicePassword", "WebStorePassword");

    this.SetConfigurationSection("Westwind.WebStore");
    this.ReadKeysFromConfig();
}

Make sure to recompile the project. Once this is done the AppSettings section in web.config will be completely clear text and you can manually edit all keys. Note that you will have to re-enter any previously encrypted keys so be careful to make the above change only if you can re-enter any critical keys correctly!

WestwindAdminService and Forms Authentication

The Web Store includes a Administration Web Service that can be used to download orders and update inventory etc. Because the service has access to sensitive data the service is located in the /Admin directory and is meant to be protected by Web security.

The service can use Windows Authentication just fine and any Web Service client will be able to access the service without any problem. However, when Forms Authentication is enabled the service will fail because Forms Authentication uses HTML to validate users. In short - this simply will not work.

You can move the Admin Web Service into another directory which is not protected by Forms Authentication, but no matter what you do, do not place it in a folder without any security! The Web Service allows downloading of order information including credit card information, so this is dangerous!

You will need to secure the Web Service with Windows Authentication or otherwise it currently is not possible to securely use this service.