Documentation / Administration

Users

Invite teammates, manage membership, onboard B2B external collaborators, and control who can sign in to your Nexus instance using your existing Microsoft Entra ID identities.

This page is for tenant administrators who own access governance for a Nexus by Stingray deployment. It covers who can sign in, how people (including external collaborators) are added and removed, how automation authenticates differently from people, and how membership connects to the role model that decides what someone can actually do.

Identity comes from your Entra ID

Nexus runs inside your own Azure subscription and authenticates people against your organization's Microsoft Entra ID (Azure AD) using OAuth2 with PKCE. Nexus does not store passwords and does not maintain a parallel identity directory. Every user who signs in is a real directory identity from your tenant, which has concrete consequences:

Your policies apply automatically. Conditional Access, MFA, sign-in risk policies, session lifetime, and joiner/mover/leaver lifecycle you already enforce in Entra ID apply the moment someone reaches Nexus. There is no second set of security controls to configure or keep in sync.
Disabling in Entra ID ends access. Deactivating or blocking someone in your directory removes their ability to authenticate to Nexus, exactly as it removes access to your other corporate apps. There is no separate Nexus password that could outlive an offboarding.
No shared logins. Every action in Nexus is attributable to a named directory identity. Audit records carry the Entra ID user or application that performed each action, so "who did this" always resolves to a real person or a registered app.

Tokens issued during sign-in are stored by the desktop client in the operating system keyring — never in plain files, browser local storage, or page JavaScript — so a stolen file or a compromised web context does not yield a usable session token.

People vs. automation

Nexus draws a hard line between interactive people and machine callers, and they authenticate through different paths:

Principal	How it signs in	Typical use
User	OAuth2 + PKCE against Entra ID (interactive)	A person authoring reports, running pipelines, or using an AI agent
Application	Scoped app token / API key (client-credentials)	Scheduled jobs, integrations, external systems, CI

Automation should authenticate as an application, not as a person. Application principals are registered separately, carry their own scoped roles, and are revocable independently of any employee's account — so a scheduled job keeps running when its author changes teams, and you can rotate or revoke a machine credential without disrupting a human. Both principal types are governed by the same RBAC engine (see Roles & Permissions); there is no weaker back door for machines.

Inviting and removing people

Administrators manage membership from the desktop app or the management API. The core operations are:

Action	What it does
Invite a user	Grants an existing Entra ID identity access to this Nexus instance and assigns an initial role.
Update a user's role	Changes what the person can see and do without re-inviting them.
Remove a user	Revokes the person's membership and their associated grants in this instance.

Inviting a user makes an existing directory identity a member of this Nexus instance — it does not create a new account in your directory, and it does not change anything about that identity elsewhere. To invite someone you supply their identity and the role they should start with. Assign the least-privileged role that still lets them do their job; you can broaden access later.

Removing a user revokes their membership and their permission grants in Nexus. Their underlying Entra ID identity is untouched, so their other corporate access is unaffected. Because sign-in is gated on the directory, disabling the identity in Entra ID is an equally effective (and often preferable) way to cut access instantly during an urgent offboarding — Nexus honors the directory's verdict on the next token validation.

B2B external collaborators

Many deployments need to bring in a contractor, a partner, or a client-side collaborator who does not have an account in your home tenant. Nexus supports this through Microsoft Entra B2B, and it is governed by an explicit tenant switch rather than being on by default.

Off by default. External-user onboarding is controlled by an "Allow External Users" setting chosen at deployment time. When it is off, only identities from your own directory can be invited — there is no path to bring in a guest.
Standard Entra B2B guests. When enabled, inviting an external email address creates (or reuses) a normal Entra ID guest object in your directory via Microsoft Graph. The guest then signs in through the standard B2B flow and is subject to the same Conditional Access, MFA, and lifecycle policy you apply to any guest in your tenant.
Same RBAC, same audit. An external collaborator is just another member once invited. They hold whatever role and scoped grants you assign — nothing more — and every action they take is attributed to their guest identity in the audit trail. Start them tightly scoped (a single collection or a handful of reports) and widen only as needed.
Governed centrally. Because guests live in your directory, your existing access reviews, guest-expiration policies, and entitlement management apply. Removing the guest in Entra ID ends their Nexus access the same way it does for an employee.

Enabling external users is a deliberate, auditable posture change: it is a provisioning-time checkbox plus the Graph permission that lets the instance's managed identity issue invitations. If your deployment must never admit outside identities, leave it off and the capability is simply absent.

Membership is only half the story — roles decide capability

Being a member lets someone sign in. Roles and scoped grants decide what they can do once inside. Nexus uses per-resource, fine-grained RBAC, so a role can grant broad access or be narrowed to specific named resources.

A grant can be:

Unscoped — applies to any resource of that type (for example, a Reader who can read every report).
Scoped — narrowed to named pipelines, reports, collections, bridges, sites, or tools, so a user only sees the resources they have been explicitly given.

Scoped grants are expressed as a small JSON object naming the resources a role may touch:

{
  "pipelines":   ["sales-nightly"],
  "reports":     ["*"],
  "collections": ["finance"],
  "bridges":     ["warehouse"],
  "tools":       []
}

Here the role can run one named pipeline, read every report, work within the finance collection, and use the warehouse bridge — and nothing else. The identical model applies to people and to applications, so a low-privilege contractor and an automation key are evaluated under one consistent set of rules. The full role model — bundled roles, per-resource semantics, and execution roles that let a curated job run with elevated permissions without permanently elevating the caller — is on the Roles & Permissions and Execution Roles pages.

A typical onboarding flow

The person already exists in your Entra ID tenant (an employee), or — if external users are enabled — is invited as a B2B guest, which creates their directory identity first.
An administrator invites that identity into Nexus with a starting role, ideally scoped to just what they need.
The user signs in through the desktop app and authenticates against Entra ID (Conditional Access / MFA apply here).
As responsibilities grow, an administrator updates their role or adds scoped grants.
When they leave the team, an administrator removes them from Nexus; disabling or expiring them in Entra ID also ends their ability to sign in — either action is sufficient.

Good practices

Start least-privilege. Assign the narrowest role that works, then widen. This is doubly true for external guests.
Prefer scoped grants for contributors who only need a handful of pipelines or reports.
Use applications, not people, for automation so machine access is auditable and revocable independently of any employee.
Govern lifecycle in Entra ID. Let your existing joiner/mover/leaver and guest-access-review processes drive Nexus access rather than managing it in isolation.
Keep "Allow External Users" off unless you have a concrete need; treat enabling it as a reviewed posture change.