Identity and device trust

Explains how members sign in, the identity-provider rule a bot's computer needs, the factors that work from inside it, and what a revocation ends. Single sign-on arrives in a later release; a team's SCIM directory sync is live and is part of the Enterprise plan.

How members sign in

The hosted login page offers, in order: Continue with email (a six-digit code typed in the same tab that asked for it), a divider, then Continue with Apple, Continue with Google, Sign in with Microsoft and Continue with GitHub — each rendered only when its provider client is configured (BOTSEON_SIGNIN_*, names only, never a value). There are no passwords and no phone numbers. An invitation arrives as a link (org.member_invited); the home edition signs its owner in with one click and is unchanged.

Single sign-on and directory sync

On Organisation → Members the row Single sign-on is present and disabled — it waits for a customer who asks — with the reason quoted: Single sign-on arrives in a later release. What it will mean when a customer asks: SAML or OIDC sign-in, a required-SSO switch, and one identity-provider application whose assignment is widened rather than a second application stood up beside it.

The section SCIM directory sync on the same page is live for a team on Enterprise or its two-week Enterprise trial; on a Team plan it shows SCIM directory sync is part of the Enterprise plan. instead, and the SCIM endpoints refuse the team's token. There an administrator presses Create token, gives the identity provider the SCIM base address (/api/scim/team/v2 under the deployment's public address) and the token, which is shown once, and can Revoke it. A request with a wrong, missing or revoked token is refused with one 401 and changes nothing. An enterprise over several teams has its own SCIM token on Organisation → Enterprise instead.

With a token, the identity provider manages the team's members through Users. A user it creates becomes a member at once: an account is created for an address that has none, and an existing account is linked rather than duplicated. A change of name or address shows on the Members page; it reaches the account itself only when the directory created that account. A user it sets inactive or deletes stops being a member, their connections in the team are revoked, and every session that had the team open falls back to the person's own organisation. The directory never removes the last owner, and the team's member limit and an unpaid invoice refuse a new member exactly as they refuse an invitation.

Groups the identity provider pushes appear on Organisation → Groups marked Synced and read-only, and a Team Bot can be assigned to one like any group. An administrator can map a synced group to a role under Role from directory; its members then hold that role, and the Members page shows it as Set by directory with no control to change it. Every change the directory makes is on the audit log with the actor SCIM (directory).

The bot's computer is an unmanaged Linux session

A device-trust rule — a managed, registered or compliant-device check, or a phishing-resistant-only policy — cannot be satisfied from inside a bot's computer, and a sign-in that requires one fails there on day one. The recommended rule, as Botseon's own advice and not the identity provider's documentation:

• Okta — a rule scoped to device platform Other Desktop, device state Any, requiring a password plus another factor, placed above the managed-device and deny rules.
• Microsoft Entra — a conditional-access policy that includes Linux and excludes Windows and macOS, granting access on MFA only, started in report-only mode before it is enabled. Group assignment in Entra needs P1 or P2 licensing and excludes nested groups.

Which factors work in the computer's browser

Plugin sign-in is unaffected

A plugin's OAuth round trip runs in the control plane, never inside the computer's browser, so an identity-provider rule scoped to the computer does not touch it.

Named failure modes

Revoking a member

Organisation → Members Remove ends the member's access (org.member_removed) and syncs seats (billing.seats_synced). Organisation → Computers Stop (Sm-49's screen) stops the member's computer and keeps its disk, on every team plan. Recreating or ending a member's computer, and ending unused computers automatically, are Enterprise features; on a Team plan the screen says Recreating and ending members’ computers, and ending unused ones automatically, are part of the Enterprise plan. A member's own devices are theirs; the product's own sign-in sessions last thirty days, so an identity-provider revocation ends access inside the product only through SCIM directory sync until single sign-on exists. A person the directory sets inactive or deletes is removed exactly as Remove removes them: they stop being a member, their connections in the team are revoked, and every session that had the team open falls back to their own organisation. Their sign-in on their own devices stays theirs; the hosted computer stays on Organisation → Computers, untouched, for an administrator to Stop or end. Without SCIM, Remove is the verb that ends access. A persistent browser login on the computer survives an ordinary image update and ends only with Reset on Settings → Updates (Sm-52).