Roles and permissions

Four roles, most privileged first. Each is its own tier: an admin is not a second name for an owner.

New after v0.2.1. The owner tier on this page — only an owner makes, re-roles or removes an owner, saves the identity provider, or adds or verifies a domain — ships in the first garboard release after v0.2.1. In v0.2.1, an admin can also do each of those; the last-owner guard applies either way.

Which actions need which role

Owner is a boundary

Only an owner grants the owner role, and only an owner changes the role of, or removes, someone who is an owner now. An admin who tries any of the three is refused with owner role required, and nothing changes. The rule covers adding people too: an admin cannot add anyone as an owner, and because adding somebody who is already in the organisation rewrites their role, an admin cannot use it to re-role an owner either.

The last-owner guard could not do this on its own. It counts owners, and a count cannot tell who is acting: an admin able to grant ownership could make themselves an owner and then demote the original, and at the moment of the demotion there would still be two. The guard stops an organisation being left with no owner. The boundary decides who may change an owner at all. Both apply, the boundary first — so an admin acting on the last owner is told owner role required, never the guard’s advice to promote someone else.

How someone becomes an owner

• An owner makes them one. Nobody else can.
• They create the organisation. Signing up does this. So does creating a new organisation, which an admin of their current one may do; accepting a workspace invitation, which creates the guest’s own new organisation; and a first sign-in through the instance’s own SSO (GARBOARD_OIDC_ISSUER), which provisions an organisation for the new account. Nobody’s ownership is being granted there: the organisation did not exist a moment before.
• Never by a seat invitation. One that names the owner role is issued as member.
• Never by signing in through your organisation’s identity provider. A first sign-in joins as member, and signing in never rewrites anyone’s existing role.

Choosing the identity provider is an owner’s act

At a domain your organisation has verified, its identity provider signs in as every account there — owners included. So whoever chooses the provider chooses who can sign in as an owner, which puts that choice on the owner’s side of the boundary.

Saving the provider (issuer, client ID, client secret), adding a domain and verifying one are therefore owner-only. An admin can still read the configuration, test the connection and turn enforcement on or off: none of those chooses anybody’s identity, and enforcement’s checks run against whichever provider an owner bound. See per-organisation SSO.

Why break-glass is admin-only

It is the one control that lets a merge proceed past a blocking finding. Every member being able to use it would make it the path of least resistance, and a break-glass everyone can pull is not a break-glass — it is a bypass with a dramatic name.

Owners keep the password door

When enforced SSO is on, everyone else must sign in through the identity provider — admins included — but owners keep password sign-in, and every break-glass sign-in through it is recorded as the session is minted.

That is deliberate. The obvious design refuses password logins for the whole organisation, and it has one failure mode that matters more than the feature: the identity provider breaks, or was misconfigured, and nobody can get in. Support tickets, a database edit, an outage. So the requirement is not absolute, and the escape hatch is audited instead.