Skip to main content

Security Model

aprity implements a multi-layered security architecture designed for enterprise Salesforce environments. This page describes each security layer, how they work together, and why they matter for your organization.

Security Architecture Overview​

aprity's security model operates at four levels:

  1. Authentication -- JWT Bearer flow (no passwords stored)
  2. Request integrity -- HMAC signing on every API call
  3. Data isolation -- Tenant-scoped partitions in the database
  4. Infrastructure -- Azure France Central with encryption at rest and in transit

Layer 1: JWT Bearer Authentication​

aprity authenticates to your Salesforce org using the OAuth 2.0 JWT Bearer flow. This is a certificate-based authentication mechanism defined in the OAuth specification.

How it works​

  1. aprity generates a JWT token containing your org's identity claims.
  2. The token is signed with a private key stored securely on the aprity cloud platform.
  3. Salesforce verifies the token using the public certificate you uploaded to your Connected App.
  4. If valid, Salesforce issues an access token that aprity uses to read metadata.

Why this matters​

  • No passwords are stored or transmitted. Authentication relies entirely on cryptographic keys.
  • No user interaction required. The JWT flow operates without a browser-based login, making it suitable for automated scans and scheduled runs.
  • Certificate-based trust. You control which certificate is authorized in your Connected App, and you can revoke access at any time by removing or replacing the certificate.
info

aprity only requests read access to metadata. It does not create, update, or delete records in your Salesforce org.

Layer 2: HMAC Request Signing​

Every API call from your Salesforce org to the aprity cloud platform is signed using HMAC-SHA256 (Hash-based Message Authentication Code).

How it works​

  1. When your org is registered, aprity generates a unique tenant-specific secret key.
  2. For each API request, the aprity managed package computes an HMAC signature over the request payload using this secret.
  3. The signature is included in the request headers.
  4. The aprity cloud platform independently computes the expected signature and compares it to the one received.
  5. If the signatures do not match, the request is rejected.

What this protects against​

  • Request tampering -- Any modification to the request payload invalidates the signature.
  • Replay attacks -- Timestamps in the signed payload prevent reuse of captured requests.
  • Impersonation -- Without the tenant-specific secret, no third party can forge valid requests.

Layer 3: Tenant Isolation​

aprity is a multi-tenant platform. Every piece of data -- scan results, metadata, documentation, feedback -- is scoped to a specific tenant.

Partition-based isolation​

Data is stored in Azure Cosmos DB using partition keys that include the tenant identifier. This means:

  • Queries for one tenant physically cannot return data from another tenant.
  • There is no shared state between tenants.
  • Each tenant's data is isolated at the database engine level, not just at the application level.

Org-level scoping​

Within a tenant, data is further scoped by Salesforce Organization ID. A tenant with multiple connected orgs maintains separate documentation sets for each org.

Layer 4: Infrastructure Security​

Azure France Central​

All aprity infrastructure runs in the Azure France Central region (Paris). This includes:

  • Compute -- Azure Container Apps for API and worker services.
  • Database -- Azure Cosmos DB for scan data, metadata, and configuration.
  • Storage -- Azure Blob Storage for generated documentation files.
  • Secrets -- Azure Key Vault for cryptographic keys and service credentials.

Encryption​

ScopeMethod
Data at restAES-256 encryption managed by Azure
Data in transitTLS 1.2+ for all communications
SecretsAzure Key Vault with managed identity access

Network security​

  • All API endpoints are HTTPS-only.
  • No data is transmitted over unencrypted channels.
  • Azure networking controls restrict access to internal services.

Data Flow Summary​

The following describes a typical scan request flow and the security controls at each step:

  1. User clicks Generate in the aprity Salesforce app.
  2. The managed package constructs an API request and signs it with HMAC.
  3. The request is sent to the aprity cloud platform over HTTPS/TLS 1.2+.
  4. The platform validates the HMAC signature and identifies the tenant.
  5. The platform authenticates to the user's Salesforce org using JWT Bearer.
  6. Metadata is extracted using the Salesforce API (read-only).
  7. Analysis and documentation are generated within the tenant's isolated partition.
  8. Results are stored in encrypted Azure storage scoped to the tenant.
  9. The Salesforce app retrieves results through another HMAC-signed call.

Compliance Alignment​

aprity's security architecture aligns with common compliance frameworks:

RequirementHow aprity addresses it
Data residency (EU)All data in Azure France Central
Encryption at restAES-256 via Azure platform
Encryption in transitTLS 1.2+ on all endpoints
Access controlJWT Bearer + HMAC + permission sets
Audit trailScan history with timestamps and correlation IDs
Data minimizationOnly metadata is read; no business data is accessed
Right to erasureMetadata purge feature available on request