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:
@@ -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).
|
||||
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user