Documentation

14 of 187 pages

Organisation Portal

Organisation Security

Configure enterprise identity and access for all member workspaces: SAML/OIDC SSO, SCIM 2.0 provisioning, TOTP MFA, session limits, step-up authentication, and audit retention.

Organisation Admin only. Policies set here apply to every workspace in the organisation and cannot be weakened by workspace admins. IdP credentials are stored in Amazon Cognito — never in the browser.

Single Sign-On (SSO)

Enable Enforce SSO and choose SAML 2.0 or OpenID Connect. Enter your IdP metadata URL (SAML) or issuer URL + client ID (OIDC). Users sign in from the login page with their organisation ID and the Sign in with SSO button.

Optional Auto-Provision adds federated users as Developer members on all org-linked workspaces on first login.

Only the organisation’s owner can configure the provider: it decides who can sign in as this organisation’s members, including administrators.

Public documentation: Enterprise Identity & Access · Security architecture

SCIM 2.0 provisioning

Click Enable SCIM to generate a bearer token (shown once). Configure your IdP provisioner with:

  • Base URL: /scim/v2
  • Authentication: Bearer token
  • Groups: Developer, Admin, Stakeholder, OrgAdmin (maps to workspace personas and org admin)

Rotate the token periodically. De-provisioning disables the Cognito account and removes memberships.

The OrgAdmin group makes organisation administrators only while the token in use was issued by the organisation’s owner. Administrators can release studios, so who becomes one is the owner’s decision: a token another administrator issued keeps users and personas in step but makes no administrator, and the refused attempt is on the security trail. The SCIM card says which kind of token is in use.

Administrators and their authority over studios

An organisation administrator can write and activate guardrail policies, read the exceptions register, place a legal hold on a studio’s work, and release a studio from the organisation. Because of that, who becomes an administrator — and what can make one — is the organisation owner’s decision by every route.

ActionWho
Add an administrator, or send an invitation to become oneThe owner only. An invitation is accepted only if the organisation’s current owner sent it, and only by the account it was sent to
Remove an administratorThe owner, or the administrator themselves
Configure the single sign-on providerThe owner only
Issue, rotate or disable the SCIM tokenThe owner only. Any administrator can see whether SCIM is on
Your identity provider manages the administrators it made. Taking someone out of the OrgAdmin group, or pushing a group that leaves them out, removes the administrator role only from a person SCIM itself made an administrator. Someone the owner appointed, or who accepted the owner’s invitation, stays until the owner or that person removes them.
De-provisioning or deactivating a user removes their administrator role whoever appointed them — except the organisation’s owner. Reactivating the user does not give it back, and a deactivated user is never made an administrator.
If the owner appoints someone SCIM made an administrator, that person becomes the owner’s appointment: a later group change no longer removes them.
Workspace Admin through the group is set only for administrators SCIM made. The owner’s appointments keep whatever workspace roles they have.
A token another administrator issued before this rule keeps working: it cannot make an administrator, but de-provisioning through it still removes one. The SCIM card says whether the token in use is the owner’s, with Rotate beside it for the owner.

A one-person organisation is unaffected: its owner is its only administrator. Who may do what across guardrails, exceptions and passports is set out in Who May Do What.

Multi-Factor Authentication

Enable Require MFA to mandate authenticator-app TOTP for all members. Users enrol at Account → MFA (/account/mfa). The API returns MFA_REQUIRED when policy is active but the session lacks an MFA claim.

Step-up authentication & session limits

Step-up window (minutes) — Destructive actions (delete workspace, RBAC matrix changes, org admin removal) require a recent sign-in within this window. Users confirm it is them in a dialog over the page they are on, with their password and then their authenticator code when they have one.
Maximum session length (hours) — Users must sign in again after this period (enforced via Cognito auth_time).
Audit log retention (days) — Default 365. Organisation and workspace audit rows expire via DynamoDB TTL after this period.

IP allowlisting

Add CIDR ranges when Enforce IP allowlist is enabled. Workspace and organisation API routes evaluate the client source IP on every request; violations return 403 IP_RESTRICTED.

Workspace override permissions

Control whether workspace admins may add supplementary IP rules, configure local SSO, or downgrade MFA below the organisation baseline. Keep MFA downgrade disabled unless security governance explicitly approves it.

Platform abuse protection (MDTS-operated)

Independent of organisation policy, the platform enforces:

  • Per-IP rate limits on sign-in, registration, password reset, and workspace join
  • 256 KB request body cap on mutating API routes
  • JSON Schema validation on authentication request bodies
  • Maximum 10 workspaces per user account (creation cap)
  • API Gateway stage throttling for platform-wide back-pressure

Managed AWS WAF on CloudFront is planned when a contract or abuse metrics justify its standing cost (a monthly fee per Web ACL and per managed rule group, charged even with no traffic). See Security architecture and System status.

All Organisation Portal documentation

Build v0.3.2 · deployed 2026-10-19T23:52:31Z