Invite and manage users

People get access to a boundary in one of two ways: someone assigns a role to a user who can already sign in, or someone invites them by e-mail. This page covers invitations and the Identity page; assigning roles is described in Assign a role.

Invite a user

Sending, resending and revoking invitations needs boundaries/invitations/create on the boundary; Owner and Platform Owner have it, Contributor does not.

1. Open Settings → Identity in the sidebar and the Invitations tab, and choose Invite user. The same sheet opens from Access control (IAM): when a member search for an e-mail address finds nobody, choose Invite … by email.
2. Email — enter the person's Email address. It does not matter whether they already have an account.
3. Role — pick the role they get: a built-in role such as Owner, Contributor or Reader, or one of the boundary's custom roles.
4. Scope — the whole boundary (the default), or narrow it to one resource group or one resource.
5. Choose Send invitation.

The person receives an e-mail, in English, naming who invited them and to which boundary, with a single-use link and the date it expires. The role is not named in the e-mail.

Rules the platform applies:

• An invitation is valid for seven days, unless your platform is configured otherwise.
• There can be only one open invitation per boundary and e-mail address.
• Someone who already holds that role at that scope cannot be invited to it again.
• Platform roles — Platform Owner, Platform Contributor, Platform Reader — are offered only if you hold rbac/members/write at the platform root. Their scope is fixed to the platform root, and sending one needs Owner or Platform Owner at the root, assigned to you directly or held through active just-in-time access. A role you hold only through a group does not count.

Note

An invitation is created even when the platform cannot send e-mail, and the portal still reports it as sent. If nobody receives it, ask a platform administrator to check the platform's e-mail settings.

With the CLI, in the boundary selected with -b, at boundary scope (or the platform root for a platform role):

stsh iam invite create alex@example.com --role Contributor

Accepting an invitation

The link opens the portal:

• Someone without an account enters First name, Last name and a password that meets the platform's password rules, and chooses Create account and sign in.
• Someone with an account chooses Sign in and accept invitation.

They must sign in with the address the invitation was sent to; signed in with another address, the invitation is refused — see email_mismatch. When they are in, they join the boundary's tenant and the role is assigned at the invitation's scope; the portal then opens its home page. Until then the invitation grants nothing. An invitation past its expiry date can no longer be accepted — see expired. Every refusal is listed on Invitation and password errors.

Follow up on invitations

The Invitations tab under Settings → Identity lists the invitations of the boundary selected in the sidebar, filtered to All statuses by default. Seeing it needs boundaries/invitations/read, which Owner, Contributor and Reader have. The Identity entry in the sidebar, though, is shown only to principals holding rbac/users/list, which Reader does not have; a Reader can list the invitations with stsh iam invite list.

On a Pending or Awaiting login row you can:

• Resend the invitation — a new e-mail goes out with a new link and a new expiry date; the previous link stops working. An invitation can only be resent a limited number of times; when the portal says the resend limit is reached, revoke the invitation and invite the person again — see resend_limit.
• Revoke the invitation — confirm Revoke this invitation?. The link stops working and the recipient is told by e-mail. An accepted invitation cannot be revoked: remove the role assignment instead.

With the CLI:

stsh iam invite list
stsh iam invite resend <invitation-id>
stsh iam invite revoke <invitation-id>

Find users

The Users tab under Settings → Identity lists who has access:

• This boundary — everyone with a role in the boundary selected in the sidebar, assigned directly, through a group or through active just-in-time access.
• Entire platform — every user on the platform, with the boundaries each has a role in. This switch is only shown to principals who can list all users at the platform root — Platform Owner, Platform Contributor and Platform Reader.

The Groups tab lists groups, and Service Accounts the boundary's service accounts — see Service accounts. The Identity entry in the sidebar is shown to principals holding rbac/users/list.