docs: update auth spec for greenfield approach

Remove migration/backward-compat hedging. Delete legacy user/role/permission
tables entirely, remove bootstrap_token column in favor of api_keys table.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
hsiegeln
2026-04-05 12:19:09 +02:00
parent fc4c1f94cd
commit c61c59a441

View File

@@ -347,7 +347,7 @@ These files are removed entirely:
Remove the `PasswordEncoder` bean from `SecurityConfig.java`.
Database migrations V001 (users table), V002 (roles/permissions tables), V003 (default role seed) should be replaced with a single migration that drops these tables if they contain no production data, or left as-is and simply unused if data migration is a concern.
Database migrations V001 (users table), V002 (roles/permissions tables), V003 (default role seed) are deleted entirely — greenfield, no production data. Replace with clean migrations containing only the tables actually needed.
#### DELETE: Ed25519 key configuration
@@ -609,7 +609,7 @@ var key = apiKeyService.generate();
// Return plaintext to caller (shown once, never stored in plaintext)
```
The `bootstrap_token` column on `EnvironmentEntity` becomes the plaintext API key that's injected into the server and agent containers. In a future migration, rename this column to `api_key_ref` or similar. For now, keep the column and populate it with the generated key.
The `bootstrap_token` column on `EnvironmentEntity` is removed. API keys are managed exclusively through the `api_keys` table. The plaintext is returned once at creation time and injected into server/agent containers.
#### REWRITE: Frontend auth
@@ -715,25 +715,20 @@ The bootstrap script already creates the API resource and roles. Verify that the
---
## Migration Strategy
## Greenfield Approach
This is a new development — no production data exists. All database schemas, migrations, and code are written fresh without backward-compatibility constraints.
### Database
1. **New migration V011**: Create `api_keys` table.
2. **New migration V012**: (Optional) Drop `users`, `roles`, `permissions`, `user_roles`, `role_permissions` tables. Or leave them unused — no runtime cost, avoids risk.
3. The `bootstrap_token` column on `environments` stays for now. Its value becomes the API key plaintext (stored temporarily for injection into containers).
- **Remove** migrations V001 (users), V002 (roles/permissions), V003 (default roles) entirely. These tables are not needed — users and roles live in Logto.
- **Replace** with a single clean migration that creates only the tables needed: `tenants`, `environments`, `api_keys`, `licenses`, `apps`, `deployments`, `audit_log`.
- The `bootstrap_token` column on `environments` is renamed to `api_key_plaintext` or removed in favor of the `api_keys` table exclusively.
### Backward Compatibility
### Implementation Order
- **Agent**: No breaking change. `CAMELEER_AUTH_TOKEN` continues to work.
- **Server**: No breaking change when `CAMELEER_OIDC_ISSUER_URI` is unset.
- **SaaS frontend**: Breaking change — org role names change. Deployed atomically with backend.
- **Self-hosted**: No impact. They don't set `CAMELEER_OIDC_ISSUER_URI`, server behaves as before.
### Rollout Order
1. **Phase 1**: Update cameleer3-server (add OIDC resource server support). Deploy. Backward compatible.
2. **Phase 2**: Update cameleer-saas backend (delete custom JWT stack, add API key management, rewrite security config). Deploy with frontend changes atomically.
1. **Phase 1**: Update cameleer3-server (add OIDC resource server support). Deploy.
2. **Phase 2**: Rewrite cameleer-saas backend (clean security config, API key management, Logto-only auth). Deploy with frontend changes atomically.
3. **Phase 3**: Update bootstrap script (set OIDC env vars on server, stop reading Logto DB directly).
---