Security and Compliance

Overview

The core services of Work 365 are hosted as a SaaS application in Microsoft's public Azure Data Centers; however, the billing and subscription data are located in the customer's Dynamics 365 instance (aka Tenant).

  • US East -Virginia, USA
  • EU West- Netherlands

Work 365 integrates with different applications to pull data (such as subscription information), compute billing and then push data (such as Invoices) into integrated systems. The figure below provides an overview of the Work 365 integration landscape.

Work 365 is built on Dynamics 365 as an Application. Therefore, the integration with Dynamics 365 is implicit and pervasive. Additionally, four categories of integrations are available with Work 365, listed as follows. For more information follow through the links.

  1. Providers -
  2. Accounting Systems
  3. Payments
  4. PSA

Security and Compliance:

IOTAP is SOC 2 Type 2 Compliant. To request to SOC 2 Report an NDA is required.

Work 365 Entities

Entities are Tables/Object records available in Dynamics 365, hosted on the customer's Dynamics 365 tenant.

Standard Dynamics 365 Sales entities used by Work 365

The entities below are part of the Dynamics 365 Sales Application.

  • Account
  • Contact
  • Invoice
  • Sales Order Line
  • Price List
  • Price List Item

Work 365 specific entities (created via the Work 365 solution)

The full list of entities can be found in the Work 365 solution once it is installed. For field details review the Entities area under the version specific Documentation. Below is a limited list of the core Business entities.

  • Billing:
    • Billing Contract
    • Subscription
    • License Change Log
    • Billing Schedule
    • Non-Recurring Item
  • Payments:
    • Payment Transaction
    • Payment Profile
  • Provisioning:
    • Provider
    • Provider Invoice
    • Provider Account
  • Technical and Non-functional:
    • Configuration
    • Work 365 Job

Integrations

Dynamics 365

Work 365 apps and services access Dynamics 365 through one of two available approaches.

The Service Account approach uses OAuth 2.0 to impersonate an existing user. Upon first consent, the refresh token is obtained for the consenting user. This token is then exchanged for an access token (bearer token) for subsequent calls to Dynamics 365. The access token is refreshed periodically. The refresh token is securely stored and is used to retrieve access tokens as needed. The access tokens are transient and are never stored. The refresh token is also rotated periodically (at least once every 90 days), although this is controlled by Microsoft. This access is based on the consenting user's access to Dynamics and requires that the consenting user be assigned an appropriate Dynamics 365 license. For more information see, https://learn.microsoft.com/en-us/power-apps/developer/data-platform/authenticate-oauth

πŸ“˜

Secrets and Refresh Tokens

Secrets such as refresh tokens are managed in Azure KeyVault. Access to Azure KeyVault is provided strictly through Azure Managed Identities.

The S2S authentication approach uses the Azure Active Directory service principal created upon first consent. While the service principal can authenticate against the Dynamics 365 environment, it must be additionally authorized to do so by assigning it appropriate roles within Dynamics 365. There are no tokens exchanged or secrets stored using this approach, since the authentication is managed using Azure Active Directory. For more information see, https://learn.microsoft.com/en-us/power-apps/developer/data-platform/use-multi-tenant-server-server-authentication

Work 365 Service role

The background worker for Work 365 requires semi-privileged access to Dynamics 365. These set of permissions are encapsulated in the Work 365 Service role available as part of the Work 365 solution for Dynamics 365.

Please review the version specific Security Role provided in the Security Roles and Permissions

Microsoft Partner Center

Work 365 integrates with Microsoft Partner Center to retrieve subscription and pricing information. These details are stored in the Dynamics 365 Entities created by the Work 365 solution. The integration process uses app+user authentication as outlined in the Partner Center authentication guidelines (not all operations required by Work 365 integration support app-only authentications). Furthermore, the integration account needs to follow the Partner security requirements as outline at https://learn.microsoft.com/en-us/partner-center/partner-security-requirements

πŸ“˜

Work 365 integration implements the Secure Application Model as outlined by Microsoft at https://learn.microsoft.com/en-us/partner-center/develop/enable-secure-app-model

The actual process of connecting to Partner Center leverages OAuth 2.0 and obtains a refresh token which is then exchanged for an access token in a manner similar to the process described for Dynamics 365. It is highly recommended that a dedicated user be created for Work 365 integration to Partner Center.

The specific requirements can be found in the instructions for configuring the Microsoft Partner Center provider integration