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
Partner Portal
Form login or SAML 2.0; partner-scoped role mapping
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.

Partner Portal authentication

Section titled “Partner Portal authentication”

Partners who deliver the platform to multiple customers sign in to the Partner Portal with a form-based login by default, or federate their delivery staff through SAML 2.0 single sign-on against the partner’s own identity provider. Partner federation is a separate service-provider registration from the administrator and self-service surfaces, with its own identifier and reply URL, and it maps federated staff to partner-scoped roles. Federated staff are provisioned on first sign-in, so no separate invitation is needed. See MSP Portal.

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. Each surface, administrator, self-service and partner, uses its own service-provider endpoint, so an organization or partner can federate one surface and not another, and each with its own identity provider.

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.