Skip to main content

Users of your applications

Available

Deployed and supported. The fields and commands described here are stable within version v1alpha1.

Your applications have their own users: customers, employees, partners. StackNGO keeps a directory dedicated to your tenant for them, with nothing to install or initialize: it is there as soon as the tenant is created. These accounts sign in to your applications, through OIDC; they have no rights on the platform. You administer them from the Authentication section of the console or with sng iam.

sng tenant use acme
sng iam role create support --permission tickets:read --permission tickets:reply
sng iam user invite alice@acme.example --role support
Invitation created for alice@acme.example (valid for 168 h)
Invitation link (shown only once): https://auth.dev.stackngo.fr/t/acme/invitation/…

Two worlds not to confuse​

Tenant members (sng tenant policy)Users of your applications (sng iam)
Whoyou, your colleagues, your CI, your machinesthe end users of your applications
Where they sign inconsole, sng sso login, StackNGO APIyour applications, via OIDC (Authentication for your applications)
What it controlssng apply, secrets, policies… in the tenantthe roles and permissions your applications read in tokens
Where to manage themIAM section of the console, sng tenant policyAuthentication section of the console, sng iam
ObjectsIAMPolicy, IAMPolicyBindingusers, roles, invitations, applications, sign-in providers

A user of your applications cannot open a StackNGO session: their token is rejected by the API. Conversely, granting rights to a colleague is done with sng tenant policy attach, not with sng iam.

Prerequisites​

  • A session on the tenant: sng tenant use acme.
  • The auth:* actions: auth:ListUsers (read) is in the readonly policy; managing accounts, invitations, roles and the sign-in page (auth:ManageUsers, auth:ManageRoles, auth:ManageLoginPage) is in readwrite; reading an application's credentials (auth:ReadCredentials) requires admin. See the action catalog.

How users arrive​

Two sign-up policies, adjustable in the sign-in page:

PolicyEffect
invite (default)only people you have invited can create an account
openanyone who signs in with a sign-in method you have enabled creates their account

Inviting. sng iam user invite EMAIL [--role R]… [--expires-in-hours N] (or the Invite button in the console) creates a single-use invitation, valid for 168 h by default (1 to 720 h), with the roles to grant on arrival. The invitation link is shown only once: pass it on to the person; it cannot be read again afterwards. Pending invitations are tracked with sng iam invitation list --pending and removed with sng iam invitation delete ID.

Passwordless sign-in​

There is no password to create, store or reset. Each user signs in with one of the methods you have enabled:

  • a sign-in link sent by email;
  • a Google, GitHub, GitLab, Microsoft, LinkedIn account or an OpenID Connect provider of your choice;
  • a passkey (device access key), which the person can add to their account.

An account is tied to its email address: a person who signs in first by email then through Google, with the same verified address, gets the same account. Methods are declared in Sign-in providers.

Viewing and blocking accounts​

sng iam user list --search alice
sng iam user describe 7c1f2a6e-3b0d-4c52-9f0e-0d6a4d5b8a11
sng iam user disable 7c1f2a6e-3b0d-4c52-9f0e-0d6a4d5b8a11
sng iam user enable 7c1f2a6e-3b0d-4c52-9f0e-0d6a4d5b8a11
sng iam user delete 7c1f2a6e-3b0d-4c52-9f0e-0d6a4d5b8a11 --yes

A user is identified by their stable identifier (sub, the one in their tokens), shown by user list. The record (describe) shows their roles, last sign-in and the sign-in methods attached. Blocking an account (disable) prevents any new sign-in and any new token, without deleting anything; enable restores it. delete removes the account permanently.

Roles and permissions​

A role is a name (support, admin…) with a list of permissions: strings that your application interprets (tickets:read, billing:*). StackNGO does not enforce them: it writes them into the tokens, and your application decides. A role holds up to 50 permissions; a tenant, 100 roles.

sng iam role create support --description "Support team" \
  --permission tickets:read --permission tickets:reply
sng iam role update support --permission tickets:read --permission tickets:reply --permission tickets:close
sng iam role list
sng iam role describe support
sng iam user roles 7c1f2a6e-3b0d-4c52-9f0e-0d6a4d5b8a11 --set support,reporting
sng iam role delete support --yes
  • role create refuses a role that already exists; role update changes only what you specify and refuses to overwrite a change made in the meantime.
  • user roles --set replaces the user's list of roles.
  • The user's roles and permissions appear in their tokens (roles and permissions claims, see Authentication for your applications).

Verification​

sng iam user list
sng iam role list

Accounts and roles also appear in the console, Authentication section, Users and Roles pages.

Limits​

  • A tenant has no directory until it is enabled: commands then answer 404. Contact support if this is the case for a recent tenant.
  • At most 1,000 pending invitations per tenant.
  • The roles described here are those of your applications; they are independent of the roles and policies that govern access to StackNGO.

See also​