Security domains in SXA Storefront

Current version: 10.2

Each storefront has its own security domain by default and registered customers are not automatically authenticated on other storefronts. If you manage multiple storefronts, this means that a registered customer who can log into one storefront and make a purchase is not able to do so on any of the other storefronts you manage. To change this so that a registered customer can log into any of the storefronts, you must use the same security domain for all of them.

By default, when you create a commerce site, a locally-managed security domain with the same name as the site is created for it and Sitecore saves these changes in the Domains.config file located in the \App_Config\Security folder. This allows a registered customer to log into the storefront site. At first, the domain is only created on the Content Management (CM) instance where the scaffolding is executed. For the domain to take effect on the live site, it must also be configured on the Content Delivery (CD) instance.

In a scaled environment where the CD server instances are separate from the CM instances, the new domain must be replicated to all CD and CM instances of Sitecore.

Commerce Connect defines the Sitecore.Commerce.Providers.DomainProvider interface. SXA Storefront includes an implementation of this provider interface in the SXA Storefront foundation layer. The domain provider returns the name of the security domain that is in use to Commerce Connect and Commerce Connect passes the domain name to the external commerce system with each API call.


If you change the security domain on a site that already has customer accounts, the customers lose access to the site unless you update the domain on the accounts.

Configure a security domain for a site

You can configure the name of the security domain to use for the site in the Content Editor on the /sitecore/Content/<tenant>/<site>/Settings/Site Grouping/<storefront> item:

The Domain field

Prior to Sitecore 9.2, replicating security domains across Sitecore instances was a manual process. With the introduction of the newCxaSiteCreated pipeline, this is now done automatically as part of site creation. You can customize the site creation pipeline to include your own custom processors.

After you configure a new security domain, you must add it to the Commerce Engine environment configuration.

Add a new security domain to the Commerce Engine environment policy

When you create a new storefront security domain, you must add the new domain to the CustomerPropertiesPolicy in the appropriate Commerce Engine environment policy .json file. This is required for customers to successfully register an account on the new storefront site. You must update the environment policy .json file for all Commerce environments.

To add a security domain to the CustomerPropertiesPolicy policy:

  1. On the instance of a Commerce Engine running the DevOps role, navigate to the folder C:\inetpub\wwwroot\<CommerceEngineInstance>\wwwroot\data\Environments, and open the policy file for the shops environment for your new storefront. For example, in a default Sitecore Commerce deployment, this is C:\inetpub\wwwroot\CommerceShops_Sc9\wwwroot\data\Environments\PlugIn.Habitat.CommerceShops-1.0.0.json.

  2. In the CustomerPropertiesPolicy section, locate the "Domains" block, and add the new security domain. The following shows a configuration example with the default security domains included in the sample Commerce deployment (from the Commerce Engine SDK):

         "$type": "Sitecore.Commerce.Plugin.Customers.CustomerPropertiesPolicy, Sitecore.Commerce.Plugin.Customers",
            "PreviewProperties": {
            "DetailsProperties": {
            "AddressDetailsProperties": {
            "Domains": [

    The name of the security domain is case sensitive and must match exactly the name of the storefront site. If there is a mismatch between the security domain name and the site name, customers will not be able to register on the storefront site.

  3. Repeat step 2 to update the environment .json files of all environments that belong to the new site, including, for example, the authoring and minions environments.

  4. Use Postman to bootstrap the Commerce Engine to apply your changes to the global database.

Do you have some feedback for us?

If you have suggestions for improving this article,