Azure Data Manager for Energy (ADME)

OSDU is a standard — not a product. To run it, you need an implementation hosted on a cloud provider. Equinor uses Microsoft Azure Data Manager for Energy (ADME) as its OSDU implementation.

graph LR U[Users]:::client -->|authenticate| EID[Entra ID]:::identity CA[Applications]:::client -->|authenticate| EID EID -->|token| GW[App Gateway]:::infra GW -->|route| ADME[ADME Platform]:::platform subgraph MS["Managed by Microsoft (PaaS)"] EID subgraph "Azure — Sweden Region" GW ADME end end classDef client fill:#e3f2fd,stroke:#1565c0 classDef identity fill:#fff3e0,stroke:#e65100 classDef infra fill:#f3e5f5,stroke:#6a1b9a classDef platform fill:#e8f5e9,stroke:#2e7d32

What is ADME?

ADME is Microsoft's fully managed service for hosting the OSDU data platform on Azure. It handles infrastructure, scaling, upgrades, and security so that Equinor can focus on using the platform rather than operating it.

In practice, when someone at Equinor says "OSDU" they typically mean the ADME-hosted instance.

How ADME relates to OSDU

The APIs you call are standard OSDU APIs. Code and documentation written against OSDU generally works on ADME without changes. The key difference is identity — ADME uses Microsoft Entra (AAD) exclusively, while the OSDU standard supports multiple identity providers.

Authentication

ADME uses industry-standard OAuth 2.0 and OpenID Connect (OIDC) protocols, with Microsoft Entra ID as the centralised identity provider. All users and clients must obtain and present a valid Entra ID-issued JSON Web Token (JWT) to access ADME APIs. Tokens expire after one hour. Basic authentication and legacy credential-based access methods are not supported.

sequenceDiagram participant Client as Client App participant Entra as Entra ID participant ADME as Azure Data Manager for Energy Client->>Entra: 1. Request token Entra-->>Client: 2. Access token Client->>ADME: 3. API request + Access token Note over Entra,ADME: OAuth2 protection — valid token required ADME-->>Client: 4. API response

User authentication

For interactive user scenarios, ADME uses the OIDC authorization code flow:

The user is redirected to the Entra ID /authorize endpoint to sign in and grant consent.
Upon successful authentication, an authorization code is returned to the client application.
The client exchanges this code at the Entra ID /token endpoint to receive:
- An ID token (containing user identity details)
- An access token (used to authorise ADME API requests)

Service authentication

For non-interactive, system-to-system scenarios, authentication is handled via the OAuth 2.0 client credentials flow:

A service principal (the ADME app registration, another Entra ID application, or a managed identity) authenticates to Entra ID using its client ID and secret or certificate.
The client requests an access token for the ADME resource.
Entra ID issues a JWT access token representing the service identity.

Once identity is confirmed, ADME moves on to authorisation via the Entitlements service.

Authorisation

Authorisation in ADME is enforced by the OSDU Entitlements Service, which implements role-based access control (RBAC) using groups and roles.

Service groups control access to ADME APIs (e.g. Storage, Search, Legal). Only members of the appropriate service group can call that service's endpoints.
Data groups control access to data records via the ACL on each record.
User groups can aggregate multiple service or data groups to simplify permission management.

At Equinor, OSDU entitlement groups are integrated with Microsoft Entra ID groups, so access is managed centrally. See Entra ID Integration for how this works.

See Entitlements (ACL) for the full service access table and group details.