docs: add Enterprise section with SAML SSO setup guide

[eseidel]

Adds a new top-level Enterprise section with two pages, wired into the sidebar between Account and System.

enterprise/index.mdx

Short overview of what the Enterprise plan covers — SAML SSO, the full role set including App Manager, invoice billing and procurement, higher patch volume — linking to the existing Billing and Organizations pages.

enterprise/saml.mdx

SAML is not self-serve yet, so this page is written around what a customer needs to send us so we can create the connection by hand. Content is derived from the actual implementation (saml.server.ts, the auth.saml.* routes, and the admin saml._index.tsx form):

• What to send Shorebird — email domain, IdP entity ID, IdP SSO URL, and X.509 signing certificate. These are exactly the customer-supplied fields on the admin connection form, and all four are required (idp_certificate is NOT NULL). Sending the IdP metadata URL instead is offered as the shortcut.
• Settings to configure on the IdP — ACS URL https://auth.shorebird.dev/auth/saml/callback (the prod default; only dev overrides SAML_CALLBACK_URL), audience URI, Name ID format, blank RelayState, response and assertion signed, and that we send unsigned AuthnRequests.
• The required email attribute statement gets its own section — node-saml only populates profile.email from email, mail, or the OID, so a missing attribute statement is the most likely setup failure.
• Okta walkthrough with links to Okta docs (all link targets verified to return 200).
• Limits that fall out of the implementation — SP-initiated only (the callback requires signed RelayState, so IdP-initiated tiles won't work), one connection per email domain with the assertion email domain enforced, SSO separate from org membership, one-hour assertion age with 60s skew.

Worth a look, @easymac

The page tells customers to name any members who already have a Shorebird account created via Google or Microsoft at the same domain, since adoptOrReject throws wrong_provider when the issuer differs and their first SSO sign-in will fail. The doc frames that as something to mention in the email; the migration itself is a manual step on our side. Let me know if you'd rather word that differently or leave it out.

Also adds Okta to the Vale sentence-case heading exceptions.

npm run build passes with all internal links valid, and cspell is clean. I couldn't run Vale locally (the @vvago/vale binary isn't installed in this checkout), so the three custom rules were checked by hand — CI will confirm.

[easymac]

👍 Looks good, checked for accuracy with our config process. Wondering whether we should exclude all of the limitations/non-supported flows? People asking for them is data for us? Don't want to confuse or surprise anyone, but not sure whether we're better off with a preemptive "no" vs hearing them ask for something. No real opinion.

[eseidel]

We should document what we don’t support today with maybe a “ask us”. The vast majority of asks we can solve much faster than customers expect.

…

On Fri, Aug 28, 2026 at 10:32 AM Mac ***@***.***> wrote: ***@***.**** approved this pull request. 👍 Looks good, checked for accuracy with our config process. Wondering whether we should exclude all of the limitations/non-supported flows? People asking for them is data for us? Don't want to confuse or surprise anyone, but not sure whether we're better off with a preemptive "no" vs hearing them ask for something. No real opinion. — Reply to this email directly, view it on GitHub <#633?email_source=notifications&email_token=AADU2TJ6GM3NVHMQIYO4FJT5MG62TA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTKMBVGM2TAMZXGY32M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#pullrequestreview-5053503767>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADU2TO76PSBW6I54V2NXGL5MG62TAVCNFSNUABFKJSXA33TNF2G64TZHM3DGMRRGI3DANBYHNEXG43VMU5TKMRYGA2DCNBSHE22C5QC> . You are receiving this because you authored the thread.Message ID: ***@***.***>