Skip to content
ATLAS
 Docs
On this page

Identity and access#

Your organisation's identity provider signs you in, and ATLAS decides what you can do. Access is denied unless a rule grants it.

Two separate questions#

Question Answered by
Who are you? Your organisation's own sign-in (Microsoft Entra ID or another OpenID Connect provider). ATLAS has no separate password.
What may you do? ATLAS, which reads your role and memberships on every request.

AI traffic takes a separate path. The gateway authenticates an API key, not a sign-in. It refuses keys of suspended organisations and of disabled owners.

Signing in#

People use the company account they already have. Everyone uses the same branded sign-in page.

  1. Enter your email address. ATLAS routes you to your organisation's identity provider by email domain.
  2. Sign in there. ATLAS then loads your role and organisation.
  3. Next time, ATLAS remembers which provider you used and sends you straight there.

Key behaviours:

  • Unknown domain. An email domain that no organisation has registered ends on an Organization Not Recognized page. There is no password fallback.
  • Light session. ATLAS loads your role, organisation and permissions at sign-in and refreshes them while you use the app. A temporary backend problem therefore can't leave you in a half-signed-in state.
  • Matches the app. The sign-in page follows the light or dark mode you were using.

Your identity comes from your provider#

Your email and name come from your organisation's identity provider, on the first and every later sign-in.

  • No extra first-login form appears.
  • If the provider supplies no usable email, ATLAS creates no account and refuses you. The email is how ATLAS recognises returning users, so it never guesses one.
  • Your username is your email address and follows it if it changes.
  • A name edited in ATLAS isn't overwritten by later sign-ins.
  • Where ATLAS manages roles, a first sign-in with a registered email domain makes you a Member. Where your identity provider manages roles, you need a mapped group.

Roles and levels#

Roles exist at three levels. ATLAS evaluates them independently, and they add up.

flowchart TB
    subgraph Organisation
        O["Owner > Admin > Member<br/>+ Account Manager, Auditor"]
    end
    subgraph Spaces
        SM[space manager: the space and everything below]
        SMem[space member: that space only]
    end
    subgraph Projects
        PM[project manager or member: that project only]
    end
    O -- implicitly manages all --> SM
    O -- implicitly manages all --> PM
  • Your data stays yours. Other organisations never see your spaces, projects, people or conversations. ilionx platform operators hold a separate platform role, which doesn't come from your organisation roles.
  • Spaces. A space manager's authority covers the space and everything beneath it. A space member belongs to exactly that space.
  • Projects are flat: roles apply to the project itself.
  • One person, one organisation.
  • When role changes take effect. The timing depends on the role source:
    • ATLAS roles apply on the person's next request.
    • Identity provider (Entra) group roles apply at the person's next sign-in.
    • SCIM roles apply when the directory pushes the change.
  • Money and secrets stay with the organisation. Project managers can't delete a project, reveal its key secrets, allocate funding or add models. For the full list, see Roles and permissions.

Where your roles come from#

Each organisation chooses a role source:

  • ATLAS (default). Admins manage roles in the app. ATLAS adds a person with a registered email domain as a Member when they sign in for the first time.
  • Identity provider. Roles follow the provider's security groups, which Admins map to roles. ATLAS re-evaluates roles at each sign-in. It suspends or refuses a person in no mapped group. Manual role edits are locked because the provider is the source of truth. The provider never controls the Owner.

For the mapping rules, see Roles and permissions.

Microsoft Entra leaves out the group list for people in too many groups (the group overage limit). ATLAS detects this and never grants a role on incomplete information.

  • An existing member is suspended with the reason "Group overage (identity provider sent too many groups)" and can't sign in.
  • A new person is refused and no account is created.
  • Access returns automatically once the overage is gone and a mapped role is present.

What you can do depends on your role#

ATLAS checks every action on the server against your role and your relationship to the resource. The web app also hides actions you can't use. That's a convenience and never the safeguard.

  • No relationship means not found. A space, project or key you can't access looks as if it doesn't exist, including anything in another organisation. This stops people from probing for what exists.
  • Some relationship but too little authority means you're told you aren't allowed.
  • Budgets and model restrictions are set from above. A space can't change its own limits. For more information, see Spaces.
  • If ATLAS can't work out who you are, it refuses the request instead of allowing it with a guessed role.

Suspending and re-enabling people#

Admins, and ilionx, can lock someone out without deleting them. A disabled person can't sign in, and every personal API key they own stops working at the gateway straight away. Project keys, audit history, usage and billing are untouched. Re-enabling restores exactly the previous access with the same keys.

  • The first reason is kept. Disabling someone who is already disabled doesn't replace the original reason, who did it or when.
  • Automatic reasons are reversible. Identity-provider role resolution, domain removal, SCIM deactivation or exceeding the seat limit can cause a suspension. The system applies and lifts these reasons. Removing a domain disables that domain's members, and adding the domain back restores them.
  • Some suspensions can't be lifted in ATLAS. Admins can't lift suspensions caused by the identity provider while it is the role source. They also can't lift suspensions caused by SCIM while SCIM is enabled. Fix the cause in your identity provider, or ask your ilionx contact.
  • Names are protected. The member list shows the name of whoever disabled a person only when they belong to your organisation. Otherwise it shows that ilionx did it.
  • Guards. You can't disable the Owner until ownership is transferred, and Admins can't disable themselves.
stateDiagram-v2
    [*] --> Active
    Active --> Disabled: Admin disables (with a reason)
    Active --> Disabled: automatic (no provider role, domain removed,<br/>SCIM deactivation, seat overage)
    Disabled --> Active: Admin enables
    Disabled --> Active: automatic (role returns, domain re-added,<br/>SCIM reactivation)

Organisation suspension#

If an organisation is suspended, its people can't use the management API and the gateway refuses its API keys. Changes take effect within seconds.

SCIM provisioning#

Without SCIM, people are added when they first sign in. SCIM (System for Cross-domain Identity Management) lets your identity provider create, update, deactivate and delete users and groups before anyone signs in. It's optional, per organisation. Ask your ilionx contact to enable it, then your Admin connects your identity provider.

  • Existing members are adopted. Their spaces, budgets and keys stay unchanged.
  • Groups drive roles when SCIM is on and your role source is the identity provider.
  • Deactivating a person in your provider disables them in ATLAS, frees their seat and stops their keys.
  • Deleting a person removes the member.
  • After the cut-over, people your provider hasn't provisioned can't sign in. SCIM must provision the Owner first, so the organisation is never left without one. If you need to undo this, ask your ilionx contact.

For more information, see Provision members with SCIM.