Skip to content

Enterprise / Feature overview

Enterprise Identity Connector

Associate a verified Microsoft Entra ID account with a Ma’atara identity through organisation review. The connector verifies enterprise sign-in; the organisation authorises the resulting identity binding.

Supported provider
Microsoft Entra ID
Sign-in integration
OpenID Connect, authorisation code with PKCE
Approval
Organisation-reviewed identity binding
Availability
Configured organisations with an active licence

What it provides

  • Per-organisation Entra tenant and application configuration, with enable, disable and removal controls.
  • Verification of the Entra token signature, issuer, application audience, validity, tenant and login nonce.
  • A member claim that associates verified enterprise sign-in with proof of control of a Ma’atara identity.
  • A pending-request queue for organisation review, with approval completion and decline actions.
  • Tenant discovery and token-verification endpoints for configured native clients.

Prerequisites

  • A Ma’atara organisation identity, active organisation licence and an authorised operator able to use its institutional signing key.
  • An Entra tenant and public-client application registration configured for the bridge callback, with OpenID Connect sign-in permissions.
  • The tenant ID and application client ID recorded in the organisation’s connector configuration. The implemented flow does not require a Microsoft client secret.
  • A member with access to both their Entra account and their Ma’atara identity. An approved application return destination is required.

Connection and approval flow

  1. Configure: the organisation registers its Entra tenant and application and enables the connector.
  2. Verify: the member completes Microsoft sign-in. The bridge verifies the returned identity token.
  3. Claim: the member proves control of their Ma’atara identity and submits the association for review.
  4. Approve: the organisation reviews the request and signs the binding for registration with the resolver. A successful Microsoft sign-in alone does not create an approved binding.

Trust and data handling

Microsoft establishes the enterprise account sign-in. The bridge verifies those claims. The organisation’s institutional signing key establishes its approval of the association. The bridge does not hold that key or sign the organisation’s bindings.

The bridge processes enterprise identity claims. Pending requests retain the organisation and member identifiers, tenant, a hashed enterprise subject reference, a redacted account display value and workflow timestamps. Hashing and redaction do not make these records anonymous.

The Microsoft leg uses Microsoft’s standard OpenID Connect token verification. A Ma’atara identity binding does not make that external sign-in exchange post-quantum, or give Microsoft custody of the member’s Ma’atara private keys.

Current scope and limits

  • Microsoft Entra ID is the implemented provider. Generic SAML, other identity providers, SCIM provisioning and Microsoft Graph directory synchronisation are outside the current connector.
  • Enterprise sign-in does not recover Ma’atara keys or decrypt user content. Members still need their own identity access and recovery arrangements.
  • Directory changes and employee offboarding are not automatically synchronised into Ma’atara binding revocation. Include binding review and revocation in the organisation’s operating procedure.
  • Native discovery endpoints do not establish readiness of every desktop client. Validate the tenant registration, approval workflow and client configuration before rollout.

Ma’atara Identity · Developer documentation · Ma’atara platform