Workspace Site Auth
Optional per-workspace subdomain login with custom IdP and branding — separate from Control Plane auth.
Workspace site auth lets a workspace expose its own login experience — custom subdomain, branding, and optional external IdP — for end users of apps built on Groundfloor.
Workspace site auth is optional and separate from Control Plane auth. Workspaces can register apps and run workloads without Groundfloor Shell or workspace-level login.
Two identity planes
| Plane | Who signs in | Where | Purpose |
|---|---|---|---|
| Control Plane auth | Account admins, operators | app.groundfloor.cloud, admin.groundfloor.cloud | Manage accounts, workspaces, secrets, billing |
| Workspace site auth | App end users | {workspace}.groundfloor.cloud (or custom domain) | Access a specific workspace's published app |
Do not conflate the two. A developer integrating Shell needs Control Plane JWTs. An ISV shipping a customer-facing product may additionally enable workspace site auth for their users.
When enabled
When workspace site auth is configured:
- Control Plane provisions or links a per-workspace IdPlane realm (or external OIDC provider)
- The Shell host discovers auth mode via workspace settings
- End-user tokens are scoped to the workspace — not platform admin tokens
Shell auth modes
Federated Shell apps support three end-user sign-in modes:
| Mode | Behavior |
|---|---|
none | No end-user login — dev / internal tools |
groundfloor | Workspace site auth via Groundfloor-managed OIDC |
external | Customer brings their own IdP |
See Shell auth modes for wiring details.
Portal configuration
Account admins configure modes, users, roles, SSO brokers, branding, and activity under Administer → Authentication. See the Authentication guide.
Related
- Authentication — portal how-to
- IdPlane integration — platform realm
- Shell authentication — app developer JWT flow
- Core concepts — identity plane table