thesabear
d5f37b5787
Secrets & PKI, Secret Distribution Model, SSO & Identity, Firewall & Network Segmentation, DNS Naming Model, and Security Monitoring - the first batch of per-system write-ups linked from the new README, sourced and sanitized from the internal KB.
25 lines
2.4 KiB
Markdown
25 lines
2.4 KiB
Markdown
# SSO & Identity
|
|
|
|
## Dual-zone SSO registration
|
|
|
|
Every app that needs single sign-on gets a provider + application pair registered *per reverse-proxy zone it's exposed on* — up to two registrations for the same app, one for the browser-facing zone and one for the internal service-to-service zone. About a dozen apps also use native OIDC/SAML instead of (or alongside) proxy-based forward-auth, where the upstream app supports it directly.
|
|
|
|
The login flow is the same shape regardless of which app or which zone it's normally accessed through:
|
|
|
|
1. User opens the app on the browser-facing zone.
|
|
2. The app redirects the browser to the identity provider for the actual OAuth authorize/token exchange — and that exchange *always* happens against the internal zone's identity-provider address, even though the app itself is normally reached via the browser-facing zone.
|
|
3. On success, the browser lands back on the app's browser-facing address.
|
|
|
|
Every app-specific setting beyond this shape (token lifetime, scopes, flow type) is deliberately *not* generalized across apps — each app's own OIDC documentation gets read fresh rather than copying another app's provider config, since the details genuinely differ per vendor.
|
|
|
|
## A real platform limitation, documented rather than hidden
|
|
|
|
LDAP-based login through the identity provider's own outpost isn't viable for the primary superuser account: the outpost hides superuser accounts from LDAP directory search, so any app that requires a search-then-bind flow can never authenticate that account through LDAP. The two ways around it — creating a second non-admin account, or demoting the primary account from superuser — were both rejected as worse than the problem. Header-based forward-auth is used instead for apps in that situation, which sidesteps the LDAP search-then-bind requirement entirely.
|
|
|
|
## Git access: least privilege, not the admin account
|
|
|
|
CI and automation pushes to the internal Git server run through a dedicated, non-admin bot account with scoped write access — not through an administrator identity. Other hosts that only need to *read* (pulling code, not pushing) get separate read-only deploy keys instead of any shared credential. This keeps a compromised automation credential from ever being an admin credential.
|
|
|
|
---
|
|
Related stacks: [`stacks/identity-and-security/authentik/`](../stacks/identity-and-security/authentik/), [`stacks/platform/gitea/`](../stacks/platform/gitea/)
|