Skip to content

User lifecycle#

On a private BSR instance, the Identity Provider (IdP) is the source of truth for user identities. This page covers how the BSR provisions accounts on first sign-in, how administrators grant elevated privileges, and how user accounts are deactivated or removed.

Provision users#

New users are provisioned Just-in-Time on first sign-in. The BSR derives the BSR username from the local part of the email address (everything before the @), replacing characters that aren’t allowed in BSR usernames with -.

A BSR username must start with a letter and contain only alphanumeric characters and -.

Examples:

  • bob.smith@example.com → bob-smith
  • julia-smith+demo@example.com → julia-smith-demo

If the derived username collides with an existing BSR username or a reserved word, the BSR appends digits to make it unique. The first collision starts at 1 and appends without a separator: a second bob-smith@example.com becomes bob-smith1. Subsequent collisions continue appending digits to the previously generated suffix.

Newly provisioned users have access to any public repositories on the instance. For private repositories, an organization admin or owner adds them to organizations directly. To grant organization membership automatically based on IdP signals, see Automated organization membership provisioning.

Grant admin privileges#

A private BSR instance grants extra capabilities to administrator accounts: instance configuration, plugin management, audit logs, user lifecycle actions, and similar.

The initial administrator is set during instance provisioning. If you need an admin assigned at setup, contact Support or your Buf representative.

After the initial admin exists, an existing server admin can grant or revoke admin privileges on other accounts using the alpha buf.alpha.registry.v1alpha1.UserService.UpdateUserServerRole API with a server-admin token. There’s no self-serve UI for this today; for help promoting additional admins, contact Support or your Buf representative.

Deactivate users#

Unlike on the public BSR at buf.build, users on a private BSR instance can’t deactivate themselves. Administrators deactivate accounts; deactivation revokes outstanding tokens and permissions, which locks the user out of the BSR web UI and CLI. The deactivated user’s resources (repositories, plugins, configuration) are retained.

There are three ways to deactivate an account.

From the admin panel#

Open https://your-bsr-instance.example.com/admin/users and deactivate the user from the row’s controls.

Through the BSR API#

The deactivation RPCs live under buf.alpha.registry.v1alpha1.UserService. The calling token must hold server-admin permission; org Admin or Owner isn’t enough.

  1. Create an API token with the necessary permissions from your user settings page.

  2. Export BUF_TOKEN and the username to deactivate:

    $ export BUF_TOKEN="..."
$ export USERNAME_TO_DEACTIVATE="..."

  3. Look up the user’s ID:

    $ curl \
    -H "Authorization: Bearer ${BUF_TOKEN}" \
    -H "Content-Type: application/json" \
    -d "{\"username\":\"${USERNAME_TO_DEACTIVATE}\"}" \
    "https://your-bsr-instance.example.com/buf.alpha.registry.v1alpha1.UserService/GetUserByUsername"

  4. Extract the returned user.id, export it as USER_ID, and call DeactivateUser:

    $ curl \
    -H "Authorization: Bearer ${BUF_TOKEN}" \
    -H "Content-Type: application/json" \
    -d "{\"id\":\"${USER_ID}\"}" \
    "https://your-bsr-instance.example.com/buf.alpha.registry.v1alpha1.UserService/DeactivateUser"

Through your IdP (SCIM)#

If you’ve connected SCIM, removing or deactivating the user in your IdP triggers the same deactivation as the admin-panel flow. For setup, see SCIM.

Permanently delete an account#

Permanent account deletion isn’t a self-serve action through the admin panel. For permanent deletion, contact Support or your Buf representative.

Automated organization membership provisioning#

Two ways to put users into BSR organizations automatically:

  • Assign every user who signs in to one organization with a chosen role: contact Support or your Buf representative to configure this for your instance.
  • Map IdP security groups to specific organizations or repositories: see Manage user access with IdP groups.