Skip to content
Support
Platform

Identity and Authentication

This section covers how administrators and delegated users authenticate to the platform’s two portals. It does not cover how end users and devices authenticate to the network itself; that is performed by the individual services and is described in each service’s own section.

At a glance

Scope
Administrator and delegated sign-in (not end-user network authentication)
Administrator
Form login or SAML 2.0; optional email MFA
Self-service
Email magic link or SAML 2.0
Federation
SAML 2.0 (Entra ID, Okta, ADFS); separate endpoints per surface

Two independent sign-in surfaces

Section titled “Two independent sign-in surfaces”

The Administration Portal and the Self-Service Portal authenticate independently of one another. They have separate sign-in, separate single sign-on configuration, and separate federation endpoints. An identity that can sign in to one does not, by virtue of that, gain access to the other.

Administrator authentication

Section titled “Administrator authentication”

Administrators sign in to the Administration Portal with a form-based login by default. An organization can instead federate administrators through SAML 2.0 single sign-on against its own identity provider, in which case federated administrators can be mapped to a default role. Multi-factor authentication by email can be required for administrators.

Self-service authentication

Section titled “Self-service authentication”

Delegated users sign in to the Self-Service Portal with an email magic link by default, with optional SAML 2.0 single sign-on. Self-service sign-in does not carry administrative role mapping; a delegated user receives only the scope granted in their context.

Federation

Section titled “Federation”

Single sign-on uses standard SAML 2.0 and interoperates with common identity providers such as Microsoft Entra ID, Okta, and ADFS. Because the two portals use separate service-provider endpoints, an organization can federate administrator access and delegated access independently, or federate one and not the other.

Identity scope

Section titled “Identity scope”

An identity is global to the platform, but what it can do is determined entirely by the roles assigned to it per scope. The same person can hold administrative roles in one organization and a delegated self-service role in another, with no leakage between them. See Roles and Administration Levels.

Section titled “Related sections”

Next

Provisioning (SCIM)

Automatically provision administrators and groups from your identity provider (Okta, Microsoft Entra ID) into Netgraph using SCIM 2.0, alongside manual invites and SAML single sign-on.

Teams

Group administrators into Teams and grant roles once: every member inherits the team's roles, and a team can hold different roles in each service context.