Security domains in SXA Storefront
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:
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:
-
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 isC:\inetpub\wwwroot\CommerceShops_Sc9\wwwroot\data\Environments\PlugIn.Habitat.CommerceShops-1.0.0.json
. -
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):RequestResponse"$type": "Sitecore.Commerce.Plugin.Customers.CustomerPropertiesPolicy, Sitecore.Commerce.Plugin.Customers", "PreviewProperties": { "DetailsProperties": { "AddressDetailsProperties": { "Domains": [ "Storefront", "extranet", "CommerceUsers" "YOUR_NEW_SECURITY_DOMAIN"
NoteThe 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.
-
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. -
Use Postman to bootstrap the Commerce Engine to apply your changes to the global database.