Avensia Storefront and GDPR

Avensia Storefront do not store any customer information but uses customer information from other systems, such as Dynamics 365 and the identity provider.

Avensia Storefront and GDPR

GDPR is an abbreviation of General Data Protection Regulation and is a European directive to harmonize data privacy laws across Europe. Detailed information about GDPR is available on the official EU GDPR site at https://www.eugdpr.org

The versions of Dynamics versions used with Avensia Storefront are:

  • Dynamics 365 for Finance and Operations (D365FO).
  • Dynamics 365 for Retail (D365FR). Dynamics 365 for Retail is a subset of Dynamics 365 for Finance and Operations. Avensia Storefront supports both versions since they are the same components and the same product.
  • Dynamics 365 NAV 2018 (D365NAV). Avensia Storefront is available for Dynamics 365 NAV 2018 with the additional product suite LS NAV and LS Omni from LS Retail.
  • Dynamics AX 2012 R3 (AX). Avensia Storefront supports Dynamics AX 2012 R3.

In this documentation will the expression Dynamics refer to all versions supported by Avensia Storefront that are mentioned above. The abbreviation Dynamics 365will refer to all versions except Dynamics AX.

The Dynamics platforms are supporting business logic through a service or by components that are included in the web solution.

  • Dynamics 365 for Finance and Operations. The platform exposes Dynamics Retail Server that is used by Avensia Storefront for all business logic. Customer information is fetched and stored on the retail server.
  • Dynamics 365 for Retail. The platform architecture is the same as for Dynamics 365 for Finance and Operations.
  • Dynamics 365 NAV. Avensia Storefront for NAV uses the product suite LS NAV and LS Omni from LS Retail. LS Omni is a service that is used by Avensia Storefront for all business logic. Customer information is fetched and stored on the LS Omni server.
  • Dynamics AX 2012 R3. The platform exposes components that contain all retail business logic. The components are included in the web solution and used for all business logic. Customer information is fetched and stored through the Commerce Runtime. Commerce Runtime is used by Retail Server behind the scenes, but not by LS Omni.

Avensia Storefront doesn’t store any personal information by default. The customer information used in the Avensia Storefront Starter Site is:

  • Customer information. Customer information is persisted and managed by Dynamics. The customer information is created in Dynamics and is fetched by the starter site by calling Retail Server, Commerce Runtime or LS Omni depending on the version of Dynamics. The customer information is stored in Dynamics and is synchronized with the retail channels and online retail channels through Retail Server, Commerce Runtime and LS Omni.
  • Member information. With Dynamics 365 NAV and the product suite, LS NAV and LS Omni are a Member Entity created instead of a Customer Entity when a user registers in Avensia Storefront Starter Site. This is the default behaviour of LS NAV and LS Omni. If a customer entity is required, then the customer entity is created by LS NAV customization as a copy of the member.
  • A user account with Dynamics 365. A user account is created in the Identity Provider when a customer is added to Avensia Storefront Starter Site. The user account includes username and password and a security token that is generated by the identity provider and assigned to the customer in Dynamics 365. The mail address is by default used as a username by Avensia Storefront Starter Site. A Contact is created in Episerver Commerce database. The contact connects the access token from the Identity Provider with the Account Number for the D365 customer entity. Name and e-mail address of the user is stored in the Episerver contact.
  • A user account with Dynamics AX 2012 R3. Dynamics AX uses another approach to authenticate customers. Dynamics AX does not support the OAuth 2.0 protocol used by Dynamics 365. With Dynamics AX is all authentication made by Avensia Storefront using Episerver Customer Management. The user account is created and stored in Episerver Commerce.
  • A user account with Dynamics 365 NAV. Dynamics 365 NAV supports user authentication and stores all user account information with the customer entity. A Contact is created in Episerver Commerce database containing a name and e-mail address.

In article 4 of GDPR are different roles defined:

  • Controller. The natural or legal person, public authority, agency or other bodies which, alone or jointly with others, determines the purposes and means of the processing of personal data. The customer of the implementation of Avensia Storefront is a controller.
  • Processor. A natural or legal person, public authority, agency or other bodies which processes personal data on behalf of the controller. Avensia Storefront and its partners are processors that process information on behalf of the customer of the product.

Identity Provider

The identity provider that is distributed with Avensia Storefront Starter Site uses a Microsoft SQL Database for account information. The database may be a dedicated database, but Identity Provider may also share another database if the namespace and table names do not conflict with other tables.

The account information that may be stored in the identity provider is:

  • Password. The password entered by the user when the account is registered on the Starter Site. The user may change the password using features in the starter site.
  • Email. The email address is used as the username in the identity provider.
  • Phone. The phone number to the user is not used by Avensia Storefront but the identity provider may store phone number if used by other services.
  • Two-factor enabled. Indicates if the user has two-factor-authentication enabled or not. Default value by Avensia Storefront is to disable to two-factor authentication.
  • Lockout enabled. Indicates that automatic lockout is activated, and the user will be locked out if the authentication fails three times in a row.
  • Locked out. Indicates if the account is locked out or not.
  • Roles. The user may have zero or more roles. Avensia Storefront Starter Site does not register any role with the user account.
  • Claims. Avensia Storefront Starter Site does not register any claims for the user, but the identity provider may store claims if registered.

The identity provider information is accessed using the URL https://<identityprovider>/idmfrom a computer that has access to the provider.

Privacy by Design

Avensia Storefront is designed with privacy by design in the following way.

  • Purpose specification. There is no default specification in Avensia Storefront Starter Site. A purpose specification must be added to the implementation project using the starter site. A purpose specification is added as CMS content using Episerver standard features.
  • Collection limitation. The default implementation of Avensia Storefront only collects the minimum of information needed by Dynamics to create a customer entity and to create a sales transaction in the omni solution.
  • Data Minimization. The starter site keeps the usage of personal information at a minimum. It does not expose any personal information except where needed for the purpose.
    • My Pages/Profile page.
    • Order history and order details.
    • Checkout page.
    • Order confirmation page.
  • Reduce the risk of misuse. All personal information is stored on the customer entity in the master system. The master system is Dynamics. There is no personal information stored in any other systems. User account information is stored in Identity Provider. Episerver stores a reference between the account and the customer entity in the master system using an Episerver Contact. The Contact contains the name and the e-mail address of the customer.
  • End-to-end Security.
    • Secure destruction. There is no secure destruction of information. Removal of a user account is managed using the standard features of Episerver and Identity Provider. If an external provider is used, such as Facebook or Twitter, is the destruction managed by those services. Customer information is removed using Dynamics standard functions.
    • Encryption. A password is encrypted in the Identity provider and in Episerver. 
    • Strong access control. Access control is managed by the access control system in Dynamics and in Episerver. The default setup is:
      • Dynamics AX 2012 R3. The user account is stored and managed within Dynamics AX. Windows authentication may be used.
      • Dynamics 365. Dynamics 365 uses Azure AD for authentication of users.
      • Episerver. Episerver users are stored and maintained within Episerver. Episerver DXC uses, however, Azure AD for access control.
      • Identity Provider. Identity provider access control is stored and managed by the identity provider.
    • Logging. Default logging is enabled in Avensia Storefront. Avensia Storefront uses Episerver logging features that are based Log4Net as logging framework. Log files are by default created in the App_Datafolder of the web application. Each site in Episerver keeps its own log files. Log files are rotated per day. There is by default no personal information or references to personal information included in the logged information. Log information and log level are customized in the implementation project using Avensia Storefront.
    • Data Breach. The default tools for breach detection in Avensia Storefront and in Episerver is the logging features of Episerver. The logging must be customized in the implementation project to include information about breach attempt and data manipulation. Since Dynamics is the master system of all personal, financial and assortment information must the logging match the logging and operations in Dynamics to be able to trace events. Data breach detection may also be managed by external monitoring tools.
  • Separate component and service handling. Personal information is managed by separate components in Avensia Storefront Starter Site.
    • Dynamics is the master system of personal information of the customer entity.
    • The identity provider used with Dynamics 365 is the master system of user account information, except for Dynamics 365 NAV that manages all user account information.
    • Episerver used with Dynamics AX 2012 R3 is the master system of user account information.
    • Episerver creates an Episerver Contact with reference to the Dynamics customer.
    • My Pages is defined as an explicit Page Type in Episerver. The page type uses separate Block Types for registration, login, password management, profile management, and order history. Each block type is isolated and there are no dependencies between the block types. A block type may be used in other pages in the website than in My Pages.
  • Documentation.
    • Data Protection. Data protection and its documentation are depending on the hosting of the platforms and Avensia Storefront.
    • Privacy policy and Data Processing. A draft of a Record of Process Activities (ROPA) is distributed with Avensia Storefront as a foundation to be used in the controller’s ROPA.
  • Complaint and redress mechanism. There are no marketing features by default in Avensia Storefront. Marketing features are implemented by Dynamics or by external services such as Dynamics 365 Sales.
    • A right to prevent processing for direct marketing. There is a field in the customer entity in Dynamics 365 that indicates if the customer accepts marketing events or not. There is no option to select what kind of marketing events to accept or decline. Avensia Storefront does not implement any marketing events except for an order confirmation mail sent when a visitor submits an order. Avensia Storefront does not by default implement any function to display and collect user acceptance for marketing events.
    • A right to object to decisions being taken by automated means. Avensia Storefront does not make any decisions. It retrieves, displays, collects and sends information to Dynamics. It may use third-party systems such as Dynamics Sales for information exchange. An e-commerce solution often uses relevance and personalization based on the visitor behaviour and statistics. This is however not included in the default setup of Avensia Storefront and the relevance is calculated by an external service based on anonymous behaviour data.
    • A right to claim compensation for damages caused by a breach of the act. There is no feature in Avensia Storefront for complaint and compensations. It is solved in the implementation using CMS and external services.
  • Respect for privacy. Dynamics platforms have no support of unbundled options of terms and conditions. There is one and only one field by default indicating marketing events or not. Avensia Storefront has no default implementation of terms and conditions. Respect for privacy must be customized in the implementation using Episerver CMS and a master system storing the user accepts and declines. Requests are
      • Unbundled from other terms and conditions.
      • Without pre-ticked boxes - i.e. the user must actively opt-in.
      • Granular - with separate consent for different types of processing.
      • Named - your organization and any third parties who will be relying on consent should be named.
      • Reversible - tell people they have the right to withdraw and detail how to do it.
      • Contact information. Contact information to the Data Protection Officer.

Record of Processing Activity (ROPA)

The processor of personal information is by law required to keep a document of data inventory that describes all processes that involve personal information. The attached PDF document below contains activities that should be included in the record of processing activity by the processor.

Avensia Storefront GDPR ROPA.pdf

Known Issues and Challenges

The following challenges and issues are known in Avensia Storefront default implementation.

User Account Information

There is always an Episerver Contact created in the Episerver Commerce database. The contact contains fields for a complete person, but only name an e-mail is used by Avensia Storefront. There are some issues that may occur:

  • Using the CMS Admin interface in Episerver there is a risk that the contact information is manually updated.
  • The name and e-mail address are duplicate information since the name and e-mail is stored in the master system (Dynamics).

Disable and lock an Account

The Active and the Locked-out flags of the contact in Episerver is not honoured by default by Avensia Storefront Starter site. A user is logged in even though it’s disabled in Episerver as long as it exists and is verified by the Identity Provider and that the customer entity with the e-mail address exists in Dynamics. Note that the Blocked field of the customer entity in Dynamics is not honoured by default by Avensia Storefront Starter site. Use the Identity provider to disable or enable a user account or make a customization of the login process in Avensia Storefront to validate the contact and customer entity.

For Dynamics 365 NAV there is no identity provider in the solution. All user account validation is made by Dynamics 365 NAV and LS Omni server.

Member Entity Information

With Dynamics 365 NAV and the product suite, LS NAV and LS Omni are a Member Entity created instead of a Customer Entity when a user registers in Avensia Storefront Starter Site. This is the default behaviour of LS NAV and LS Omni. If a customer entity is required, then the customer entity must be created by LS NAV by a customization that copies the member entity. There is no interface in LS Omni server to create a Customer entity from the website.