Identity and device trust

Administrator·4 minutes to read

Explains F-ID-6's guidance — 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 — and F-COMP-4's revocation sentence, as D163 promises. Single sign-on and SCIM directory sync are later (D43).

The hosted login page offers these buttons, in order: Continue with Google, Continue with Microsoft, Continue with email (a six-digit code typed in the same tab that asked for it), a divider, then 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 rows Single sign-on and SCIM directory sync are present and disabled — deferred under D43 — with the reason quoted: Single sign-on and directory sync arrive in a later release. What they will mean when a customer asks: SAML or OIDC sign-in, a required-SSO switch, SCIM with automatic deprovisioning, and one identity-provider application whose assignment is widened rather than a second application stood up beside it.

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

Factor	In the computer's browser	Why
password + push or an authenticator app	works	the second factor completes on the member's own phone
a passkey held in a password manager the Team Setup manifest installs	works	the passkey lives inside the computer's own browser profile
a platform passkey, a hardware key, a "managed device" signal	does not work	the session is an unmanaged Linux browser; the member's own security key (`Sm-47`) sits on their own device, not the computer

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

symptom	cause	remedy
`User is not assigned to this application`	the identity-provider application's assignment does not cover this member	widen the application's assignment
a SCIM assignment without a matching SAML assignment	the account is provisioned but not authorised to sign in	add the SAML assignment; the first sign-in is blocked until it exists
an Entra group assignment that does not take	licensing or nesting	check for P1/P2 licensing and remove nested groups from the assignment
a managed-device deny rule blocks the computer	the device-trust rule above is missing or placed below a deny rule	add the recommended rule above the deny rule

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. A member's own devices are theirs; the product's own sign-in sessions last thirty days, so an identity-provider revocation alone ends nothing inside the product until single sign-on exists — Remove is the verb that ends access today. A persistent browser login on the computer survives an ordinary image update and ends only with Reset on Settings → Updates (Sm-52).

Last verified against build c0f77aa.