Accounts and access

Create a local account

A local account signs in with a username and password and is always an administrator. Give everybody else access through single sign-on and roles.

  1. Open Admin → Accounts → Users and select + Add user.
  2. Enter Display name and Username, then choose Add.
  3. Securely hand over the one-time password before dismissing the panel. The recipient must choose their own password at first sign-in. If it is lost, reset it; you cannot read it back.

Reset, disable or sign out

Choose Manage on the person's row.

  • Reset password: sign out existing sessions and issue a temporary password.
  • Disable account: sign out and block access; keep the account’s name on its past changes.
  • Enable account: allow new sign-ins without restoring old sessions.
  • Revoke sessions: sign out without changing the password. This does not block future access.
  • Rename: change the display name only.

Smeltr asks you to confirm before it resets a password or disables an account. Your own row has no Reset password: a local account uses Change password in the account menu at the top right, which shows your name. A single sign-on account changes its password at the provider.

Change session lifetimes

  1. Open Admin → System → Sessions.
  2. Set Idle timeout and Maximum session age, observing the units displayed alongside each field.
  3. Select Save sessions.

By default, a session ends after 30 minutes without activity or 12 hours after sign-in. You can set both limits from two minutes to 30 days. Idle timeout cannot exceed Maximum session age. Changes apply on each session's next request; shortening a limit can sign people out immediately. A leader restart clears all in-memory sessions, not account records.

Recover access when nobody can sign in

If you've lost your admin password and nobody else can sign in, recover access on the leader host.

  1. Stop the leader and verify there is no other instance using its data directory.
  2. Start the same binary, configuration and data under the same account, once, with the following environment setting.
SMELTR_RECOVER_ADMIN=1 SMELTR_CONFIG_FILE=/absolute/path/to/smeltr.toml /absolute/path/to/smeltr

Read the username and temporary password from the leader’s process console or service log, then sign in and change the password. Remove SMELTR_RECOVER_ADMIN from the service environment before the next restart; leaving it enabled resets the account again every time. This recovery procedure requires access to the leader host.

Sign in through single sign-on

People can sign in through your organization's identity provider over OpenID Connect (OIDC). Local accounts keep working whatever is set here, so keep at least one local administrator as a way in when the provider is down.

  1. Open Admin → System → Single sign-on and copy the Redirect URI. It is the leader's own address followed by /api/auth/oidc/callback.
  2. At your provider, register a web application (a confidential client) with that redirect URI. Have the provider name each person's groups in a groups claim of the ID token, and create a group for the people who may sign in to Smeltr.
  3. Back in Smeltr, turn on Enabled and enter the provider's Issuer URL, the Client ID and Client secret, and the Required group. If your provider names groups in another claim, set it under Advanced.
  4. Select Save.

The issuer must be an https:// URL, or an http:// URL to localhost or a loopback address, for a local test provider. Saving reads the provider's discovery document and keys, so a wrong issuer is refused when you save. The client and the groups claim are only tried at the first sign-in, so sign in once to check them. The client secret is stored encrypted and never shown again; changing the issuer or client ID forgets it, so enter the new client's secret with them.

The sign-in screen then offers Sign in with SSO, with Sign in with username beside it for local accounts. The first time somebody signs in through the provider, Smeltr creates their account. Somebody outside the required group is refused. Accounts lists them with SSO as their sign-in, and the email or username the provider gives them under their name.

The provider owns an SSO account's password, so it has no Reset password. To stop somebody signing in, remove them from the required group, or disable their account in Smeltr.

Account, role and session actions take effect immediately; they are not pipeline changes waiting for branch deployment.

Give people access with roles

An SSO account can do only what its roles give it. A role is named for one group in the provider's groups claim, and gives whoever holds that group one level in each area: the shared configuration or a worker group.

  • viewer reads the area's configuration.
  • editor also saves to it on a branch, and captures, previews and reads its samples.
  • deployer also approves and deploys changes to it.

Anybody holding an area also reads the shared configuration, which every group draws on. The Map and Status pages show only the groups a person holds. A change is shown only to someone who can view every area it touches; changing it takes an editor, and deploying it a deployer, in each of them. A change to shared counts as shared alone. Rolling back from History, or selecting Release, moves every group, so it takes a deployer in shared and in every group. Group lists name only the groups a person holds. A role marked Administrator gives everything, Admin included.

  1. Open Admin → Accounts → Roles and select + Add role.
  2. Enter the group exactly as the provider names it.
  3. Choose a level for each area, or tick Administrator, and select Save.

A change to a role applies on each holder's next request. A change to somebody's groups at the provider applies within a few minutes, while they stay signed in, when the provider issues refresh tokens and its refreshes carry an ID token; otherwise at their next sign-in. A refresh the provider refuses, or one that drops the required group, signs them out. To shut somebody out at once, disable their account in Users, or remove them from the required group at the provider and then revoke their sessions. Users lists each person's roles beside their name.