Team & Accounts
Accounts & multi-tenancy
Every resource you create — endpoints, domains, certificates, firewall rules, dedicated IPs — belongs to an account, not to an individual person. An account can be shared with teammates. The person who created the account is its owner; everyone else joins as a member. Owners and members differ only in permissions; the resources themselves are the account's.
The active account is server-authoritative: it travels in your session, so there is no account id in any URL. Switching accounts re-issues your session against the new account, and from then on every page shows that account's resources.
account_members entitlement, and the account audit log requires the account_audit_log entitlement. The owner always has access regardless of plan.Members & invitations
Manage your team from Account → Members (/account/members). The page lists current members with their role and lets you invite, change roles, remove, and transfer ownership.
Inviting a teammate
- Click Invite member and enter their email and the role to grant.
- They receive an invitation link. Accepting it joins them to the account with that role.
- Pending invitations are visible under Account → Invitations (
/account/invitations), where the owner can revoke any that haven't been accepted yet.
Roles on a member
- Owner — full control of the account, including billing, plan changes, and member management. There is exactly one owner; ownership can be transferred to another member. The owner is always exempt from the member gate.
- Member — access governed by the named role assigned to them (see RBAC below). A member's effective permissions are exactly what their role grants.
Named-role RBAC
Permissions are assigned to members through named roles, managed under Account → Roles (/account/roles). A role is a matrix of permissions over the account's resources; assign a role to a member and they inherit exactly those permissions.
The permission matrix
Each role grants permissions per resource. The resources in the matrix are:
| Resource | Covers |
|---|---|
| Endpoints | Tunnels and endpoint settings. |
| Domains | Custom domains and DNS. |
| Certificates / SSL | TLS certificate management. |
| Dedicated IPs | Requesting and attaching dedicated IPs. |
| Firewall | Firewall policies. |
| Rate Limits | Rate-limit rules. |
| Traffic Inspector | The live traffic view and Security Analytics. |
| Members | Inviting / removing teammates. |
| Roles | Creating and editing roles. |
| Account Settings | Account name and tenant-level settings. |
| Billing | Subscription, plan, payment methods, invoices. |
Create, edit, and delete custom roles to match how your team is organised. There is no “owner” role row — ownership is a property of the membership itself, and the owner implicitly holds every permission.
Single Sign-On (SSO)
SSO is configured per account. Account owners and admins manage it under Account → Settings → Single Sign-On (/account/settings/sso). SSO is gated by the sso entitlement and is keyed by email domain — users whose email matches a configured domain sign in through that provider.
Configuration fields
| Field | Notes |
|---|---|
| email_domain | The email domain this config applies to (e.g. company.com). One config per domain, per account. |
| provider_type | One of google, github, oidc, saml. For google and github the endpoint URLs are locked to the provider's canonical values and filled automatically. |
| client_id | OAuth/OIDC client ID. |
| client_secret | Provider client secret. Never returned in API responses; leave blank on update to keep the stored value. |
| auth_url / token_url / userinfo_url | Endpoint URLs for custom oidc providers (can be auto-discovered from an issuer URL). Ignored for google/github. |
| scopes | Space-separated OAuth scopes. |
| enforced | When on, matching-domain users must sign in via SSO. Turning this on requires the sso entitlement. |
| domain_verified | Read-only. Whether the account has proven ownership of email_domain (see below). oidc/saml configs only take effect at login once verified. |
Domain verification
Because a custom oidc/saml provider's identity comes from an owner-supplied userinfo_url, an account must prove it controls the email domain before that config can assert users' identities. Add the shown DNS TXT record, then run Verify:
- Host —
_ngris-sso-verify.<your-domain> - Value —
ngris-sso-verify=<token>(the per-config token shown in the dashboard)
google and github are auto-verified — their identity is asserted by Google/GitHub against locked canonical endpoints, so no DNS proof is required. Until an oidc/saml config is verified it is ignored at login (it will neither be offered nor enforced).
Enforcement & MFA
On the login page, enforcement is evaluated against the user's default account: if that account enforces SSO for the user's email domain, password login is blocked with SSO_REQUIRED and the user is sent through SSO. Signing into a different account that enforces SSO triggers an SSO step-up at account-switch time. Accounts without SSO stay on password login, so a user who owns a password account and is only a member of an SSO-enforced account is never forced through SSO just to reach their own account.
SSO does not bypass two-factor authentication: if the user has MFA enabled, they complete the SSO handshake and are then challenged for their MFA code before the session is issued.
You can test a configuration before relying on it; the latest test status and any error are surfaced on the config. A configuration starts in the active status.
Seat cap
The number of members an account may hold is capped by your plan's max members setting. The Members page shows current seat usage (members used / max). Invitations beyond the cap are rejected, and accepting an invite is re-checked against the cap so a burst of simultaneous accepts can't overshoot it.
A plan with the cap unset (or set to 0) means unlimited members. Downgrading to a plan without the account_members entitlement suspends existing non-owner memberships — they are not deleted, and re-upgrading restores them.
Account audit log
Every resource action on the account — endpoint, domain, certificate, firewall, rate-limit, API-key, dedicated-IP, billing, and member/role changes — is recorded in the account-scoped audit log. Each entry records who acted, what they did, how they authenticated, and from which device, so an owner can answer “who changed this and when.”
Personal sign-in events (password, 2FA, sessions) are not here — those live on the per-user security surfaces under your own profile, which stay strictly separate from the tenant-level account view.
account_audit_log entitlement on the active plan.