theta42/theta-suite
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #174 from theta42/docs/index-page-update

Browse Source 
Update docs home page copy
This commit is contained in:
William Mantly
2026-08-07 00:10:34 -04:00
committed by GitHub
parent 70fc19e37f 28fad8a49e
commit 403e1a3cd4
1 changed files with 60 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/index.md
+60 -48
View File
@@ -4,24 +4,28 @@ title: Home
description: A unified, one-command SSO Manager + OIDC proxy stack for home labs and small businesses. Wires together a self-hosted identity provider and a reverse proxy with one setup.sh. description: A unified, one-command SSO Manager + OIDC proxy stack for home labs and small businesses. Wires together a self-hosted identity provider and a reverse proxy with one setup.sh.
--- ---
# theta-suite # Theta suite
The whole theta42 identity, access, and secrets stack in one repo, brought up Theta Suite is your one-line solution to replacing fragmented, hard-to-wire
with a single command — for home labs and small businesses. authentication setups with a unified security stack. It wires together OIDC
authentication, LDAP user directories, automated host enrollment, and
centralized secret management in a single command. It eliminates the manual
configuration friction so you get secure access, auditability, and multi-site
replication running in seconds.
It composes four applications around a shared secrets store: ## Who This Is For
[SSO Manager](https://theta42.github.io/sso-manager-node/) (OIDC provider + * **Self-Hosters & Homelab Engineers:** Anyone running local bare metal,
LDAP directory), [Proxy](https://theta42.github.io/proxy/) (an OIDC-protected Proxmox, or private VPS nodes who wants enterprise-grade OIDC, multi-master
reverse proxy that can also look users up directly in LDAP), LDAP, PAM/SSSD host enrollment, and OpenBao secret management without spending
[Jump Host](https://theta42.github.io/jump-host/) (directory-driven SSH access days manually wiring glue code.
through one public entry point), and * **Small-to-Medium Businesses (SMBs):** Infrastructure teams that need a
[ldap-client](https://theta42.github.io/ldap-client/) (enrolls your Linux unified, directory-driven access plane across both web apps and Linux boxes,
hosts into the directory for PAM/SSSD, sudo, and SSH keys). All of them read but want to bypass per-user SaaS taxes (Okta, Azure AD) and cloud vendor
their secrets at boot from [OpenBao](https://openbao.org/), the central secrets lock-in.
store. `setup.sh` automates the fiddly part: registering the proxy as an OIDC * **DevOps & Systems Operators:** Engineers who value idempotent, single-command
client of the SSO, pointing every component at the right LDAP directory and deployments (`./setup.sh`) and need a production-grade baseline supporting
the OpenBao token it needs, and generating hostnames and secrets from one zero-trust proxying, SSH jump-host access control, and multi-site replication
`setup.env`. out of the box.
## Screenshots ## Screenshots
@@ -33,41 +37,49 @@ The SSO Manager and the proxy it fronts, both stood up by one `./setup.sh` run:
*(click either screenshot to view full size)* *(click either screenshot to view full size)*
## Why this over running them separately
The components are designed to integrate — they're only useful together once
the proxy is registered as an OIDC client of the SSO *and* pointed at the
SSO's LDAP directory — and the domain has to match across half a dozen config
fields, or logins silently fail. Doing that by hand is fiddly. `setup.sh`
asks for your domain once, generates both apps' config with it filled in
everywhere, registers the proxy as an OIDC client automatically, and
snapshots state before every rebuild.
## What you get ## What you get
- **SSO Manager**, fronted by the proxy under TLS — manage users, groups, - **Unified SSO Manager**: An OpenID Connect (OIDC) provider and OAuth 2.0
and OAuth clients. authorization server fronted by TLS. Includes a web dashboard for managing
- **Proxy** — add the hosts you want to protect with OIDC login. users, groups, and OAuth apps, plus automated invitation and password reset
- **LDAPS** for direct binds — Linux hosts (PAM/SSSD, sudo, SSH keys) and flows.
LDAP-native apps authenticate against the same directory. - **Identity-Aware Reverse Proxy**: Intercepts HTTP/HTTPS traffic to protect
- **Hierarchical groups & permissions** — every adopted host and app gets its own upstream applications with OIDC login and direct LDAP group authorization,
`admin`/`access`/`capability` groups, generated from the Directory; they double featuring automatic TLS certificate issuance and automated host routing.
as real POSIX groups for sudo/SSH. See - **Embedded LDAPS Directory**: A bundled OpenLDAP core acting as your single
[Group & Permission Model](GROUPS.html). source of truth for POSIX accounts, SSH public keys, and sudo roles. Native
- **ldap-client** — enroll Linux hosts into the directory (PAM/SSSD login, apps, legacy infrastructure, and Linux machines authenticate directly over
sudo, SSH keys); the host inventory shows up in the SSO UI and drives encrypted LDAPS (port 636) or StartTLS.
jump-host routing. - **Hierarchical Directory Group & Permission Model**: Every adopted application
- **SSH Jump Host** — `ssh uid_-_host@jump.<domain>` (WinSCP-friendly) and machine automatically inherits dedicated `admin`, `access`, and
or an interactive picker; access is driven by directory group membership, with `capability` groups generated directly from the LDAP directory. These map
a web UI for audit + metrics. cleanly to real POSIX groups for fine-grained sudo and SSH privilege controls.
- **Central secrets (OpenBao)** — every component loads its secrets from one See [Group & Permission Model](GROUPS.html).
[OpenBao](https://openbao.org/) instance at boot; each user gets personal - **Automated Linux Host Enrollment (ldap-client)**: A lightweight host agent
secret storage, and admins mint scoped tokens for external apps. See that enrolls Linux machines into the central directory. It configures system
PAM/SSSD for login, applies sudo policies, distributes SSH public keys, and
registers host telemetry in the primary inventory dashboard.
- **Directory-Driven SSH Jump Host**: A centralized bastion host that routes
inbound terminal traffic (`ssh uid_-_host@jump.<domain>`) using active
directory group memberships. Supports WinSCP, file transfers, interactive
host pickers, and a dedicated audit interface for tracking user sessions and
connection metrics.
- **Central Secrets Engine (OpenBao integration)**: Bootstraps every component
against an embedded [OpenBao](https://openbao.org/) instance to load tokens
and cryptographic keys at runtime. Provides per-user secret vaults and enables
administrators to mint scoped API tokens for external services. See
[Secrets](secrets.html). [Secrets](secrets.html).
- **Self-service API tokens** in both apps' UIs, for scripting/CI without a - **Self-Service & CI/CD API Tokens**: Granular, personal access token
browser session. management built directly into the web interface, allowing operators to drive
- **Multi-Site Support (Geo-Location Scaling)** — built-in support for N-Way Multi-Master LDAP replication across physical locations. system administration and automation pipelines programmatically without an
- **Multi-target load balancing** — built-in proxy support for round-robin load balancing across multiple application servers. active browser session.
- **Multi-Site Geo-Replication**: Built-in support for N-Way Multi-Master LDAP
replication, allowing directory states to sync across geographically separated
physical hardware or remote data centers for high availability and low-latency
local reads.
- **Multi-Target Load Balancing**: Native reverse-proxy load balancing that
distributes traffic across multiple application backends using customizable
health checks and round-robin strategies.
## Get it ## Get it