Security Model for Azure Managed Cache Service

Updated: August 25, 2015

Microsoft recommends all new developments use Azure Redis Cache. For current documentation and guidance on choosing an Azure Cache offering, see Which Azure Cache offering is right for me?

Managed Cache Service allows you to control access to your cache by requiring client applications to authenticate themselves against the cache using access keys. Managed Cache Service also provides the ability to secure channel communication between your client application and the cache. This topic provides an overview of controlling access using access keys, and securing communication with your cache.

In order to ensure that only intended client applications are able to access your cache, all clients are required to present an access key to the cache.

When you create a cache using the Management Portal, it is pre-configured with two access keys: a Primary Access Key and a Secondary Access Key. You can retrieve them by clicking Manage Keys from either the Quickstart tab for Cache or the Cache Dashboard.

Manage Access Keys for Windows Azure Cache Service

These access keys are used to configure your client application.

Typically, the Primary Access key is used, and the Secondary Access key is used to perform a rolling update when the primary access key is regenerated. This procedure is described in the following section, How to: Perform a Rolling Update.

To specify the access key for the cache in your client application, open the web.config or app.config file for the application, and find the securityProperties element in the dataCacheClients section.

<!--<securityProperties mode="Message" sslEnabled="false">
  <messageSecurity authorizationInfo="[Authentication Key]" />

Uncomment this snippet and replace [Authentication Key] with the primary access key. If the authentication key is not properly configured, clients won't be able to connect to the cache.

The securityProperties and dataCacheClients sections are added by the Cache NuGet package used to configure cache clients. For more information, see Configure a Cache Client using the Caching NuGet Package.

A secondary access key is also provided so that you can update the keys using a rolling update so that your applications don't experience downtime due to key changes.

For scenarios where you need to regenerate your primary access key, for example to comply with corporate policy, or if the access key has been compromised, you can perform the following steps.

  1. Update the configuration of your cache client applications to use the secondary access key.

  2. In the Manage Access Keys dialog in the Management Portal, click regenerate for the Primary Access Key.

  3. Update the configuration of your cache client applications to use the newly regenerated primary access key.

    Regenerate the secondary access key.

Managed Cache Service provides the ability for you to secure communication between your client application and your cache. To do so, set sslEnabled = true in the securityProperties element in the dataCacheClients section of your application's web.config or app.config file. This will ensure that all communication between the client and the cache happens over TLS.

<securityProperties mode="Message" sslEnabled="true">
  <messageSecurity authorizationInfo="[Authentication Key]" />

By default, sslEnabled is set to false, and if the sslEnabled attribute is not specified, the value used is false.

Communication between clients and caches hosted in the same Azure region is already secure. If your cache is hosted in the same Azure region as your client application, it is recommended to set sslEnabled to false. Because there is some overhead when using SSL, setting sslEnabled to true when the cache and cache clients are in the same region will unnecessarily degrade the cache performance.

If it is not possible to have both the cache and the cache client in the same Azure region, then your application could receive the benefit of encrypted communication by setting sslEnabled to true. Note that for best performance (not just in regard to the sslEnabled setting), locate the cache in the same region as the cache client application.

See Also