chore: rename cameleer3 to cameleer
Rename Java packages from net.siegeln.cameleer3 to net.siegeln.cameleer, update all references in workflows, Docker configs, docs, and bootstrap. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
hsiegeln
@@ -2,7 +2,7 @@
|
||||
|
||||
**Date:** 2026-04-05
|
||||
**Status:** Draft
|
||||
**Scope:** cameleer-saas (large), cameleer3-server (small), cameleer3 agent (none)
|
||||
**Scope:** cameleer-saas (large), cameleer-server (small), cameleer agent (none)
|
||||
|
||||
## Problem Statement
|
||||
|
||||
@@ -13,7 +13,7 @@ The current cameleer-saas authentication implementation has three overlapping id
|
||||
1. **Logto is the single identity provider** for all human users across all components.
|
||||
2. **Zero trust** — every service validates tokens independently via JWKS or its own signing key. No identity in HTTP headers. The JWT is the proof.
|
||||
3. **No custom crypto** — use standard libraries and protocols (OAuth2, OIDC, JWT). No hand-rolled JWT generation or validation.
|
||||
4. **Server-per-tenant** — each tenant gets their own cameleer3-server instance. The SaaS platform provisions and manages them.
|
||||
4. **Server-per-tenant** — each tenant gets their own cameleer-server instance. The SaaS platform provisions and manages them.
|
||||
5. **API keys for agents** — per-environment opaque secrets, exchanged for server-issued JWTs via the existing bootstrap registration flow.
|
||||
6. **Self-hosted compatible** — same stack, single Logto org, single tenant. No special code paths.
|
||||
|
||||
@@ -52,9 +52,9 @@ The current cameleer-saas authentication implementation has three overlapping id
|
||||
|-------|--------|-----------|-----------|---------|
|
||||
| Logto user JWT | Logto | ES384 (asymmetric) | Any service via JWKS | SaaS UI users, server dashboard users |
|
||||
| Logto M2M JWT | Logto | ES384 (asymmetric) | Any service via JWKS | SaaS platform → server API calls |
|
||||
| Server internal JWT | cameleer3-server | HS256 (symmetric) | Issuing server only | Agents (after registration) |
|
||||
| API key (opaque) | SaaS platform | N/A (hashed at rest) | cameleer3-server (bootstrap validator) | Agent initial registration |
|
||||
| Ed25519 signature | cameleer3-server | EdDSA | Agent | Server → agent command integrity |
|
||||
| Server internal JWT | cameleer-server | HS256 (symmetric) | Issuing server only | Agents (after registration) |
|
||||
| API key (opaque) | SaaS platform | N/A (hashed at rest) | cameleer-server (bootstrap validator) | Agent initial registration |
|
||||
| Ed25519 signature | cameleer-server | EdDSA | Agent | Server → agent command integrity |
|
||||
|
||||
### Authentication flows
|
||||
|
||||
@@ -65,19 +65,19 @@ The current cameleer-saas authentication implementation has three overlapping id
|
||||
4. `organization_id` claim in JWT → resolves to internal tenant ID
|
||||
5. Roles come from JWT claims (Logto org roles), not Management API calls
|
||||
|
||||
**Human user → cameleer3-server dashboard:**
|
||||
**Human user → cameleer-server dashboard:**
|
||||
1. User authenticates with Logto (OIDC flow, server configured via existing admin API)
|
||||
2. Server exchanges auth code for ID token, validates via provider JWKS
|
||||
3. Server issues internal HMAC JWT with mapped roles
|
||||
4. Existing flow, no changes needed
|
||||
|
||||
**SaaS platform → cameleer3-server API (M2M):**
|
||||
**SaaS platform → cameleer-server API (M2M):**
|
||||
1. SaaS platform obtains Logto M2M access token (`client_credentials` grant)
|
||||
2. Calls tenant server API with `Authorization: Bearer <logto-m2m-token>`
|
||||
3. Server validates via Logto JWKS (new capability — see server changes below)
|
||||
4. Server grants ADMIN role to valid M2M tokens
|
||||
|
||||
**Agent → cameleer3-server:**
|
||||
**Agent → cameleer-server:**
|
||||
1. Agent reads `CAMELEER_API_KEY` env var (fallback: `CAMELEER_AUTH_TOKEN` for backward compat)
|
||||
2. Calls `POST /api/v1/agents/register` with `Authorization: Bearer <api-key>`
|
||||
3. Server validates via `BootstrapTokenValidator` (constant-time comparison, unchanged)
|
||||
@@ -96,7 +96,7 @@ The current cameleer-saas authentication implementation has three overlapping id
|
||||
|
||||
## Component Changes
|
||||
|
||||
### cameleer3 (agent) — NO CHANGES
|
||||
### cameleer (agent) — NO CHANGES
|
||||
|
||||
The agent's authentication flow is correct as designed:
|
||||
- Reads API key from environment variable
|
||||
@@ -106,13 +106,13 @@ The agent's authentication flow is correct as designed:
|
||||
|
||||
The only optional change is renaming `CAMELEER_AUTH_TOKEN` to `CAMELEER_API_KEY` for clarity, with backward-compatible fallback. This is cosmetic and can be done at any time.
|
||||
|
||||
### cameleer3-server — SMALL CHANGES
|
||||
### cameleer-server — SMALL CHANGES
|
||||
|
||||
The server needs one new capability: accepting Logto access tokens (asymmetric JWT) in addition to its own internal HMAC JWTs. This enables the SaaS platform to call server APIs using M2M tokens.
|
||||
|
||||
#### Change 1: Add `spring-boot-starter-oauth2-resource-server` dependency
|
||||
|
||||
**File:** `cameleer3-server-app/pom.xml`
|
||||
**File:** `cameleer-server-app/pom.xml`
|
||||
|
||||
Add:
|
||||
```xml
|
||||
@@ -124,7 +124,7 @@ Add:
|
||||
|
||||
#### Change 2: Add OIDC resource server properties
|
||||
|
||||
**File:** `cameleer3-server-app/src/main/resources/application.yml`
|
||||
**File:** `cameleer-server-app/src/main/resources/application.yml`
|
||||
|
||||
Add under `security:`:
|
||||
```yaml
|
||||
@@ -360,7 +360,7 @@ cameleer:
|
||||
public-key-path: ${CAMELEER_JWT_PUBLIC_KEY_PATH:}
|
||||
```
|
||||
|
||||
Remove the `keys/` directory mount from `docker-compose.yml`. The SaaS platform does not sign anything — Ed25519 signing lives in cameleer3-server only.
|
||||
Remove the `keys/` directory mount from `docker-compose.yml`. The SaaS platform does not sign anything — Ed25519 signing lives in cameleer-server only.
|
||||
|
||||
#### REWRITE: `SecurityConfig.java`
|
||||
|
||||
@@ -680,7 +680,7 @@ Keep as-is. Serves frontend configuration. No auth changes needed.
|
||||
Update to set `CAMELEER_OIDC_ISSUER_URI` and `CAMELEER_OIDC_AUDIENCE` on the tenant server:
|
||||
|
||||
```bash
|
||||
# Add to the cameleer3-server environment in docker-compose or bootstrap output:
|
||||
# Add to the cameleer-server environment in docker-compose or bootstrap output:
|
||||
CAMELEER_OIDC_ISSUER_URI=http://logto:3001/oidc
|
||||
CAMELEER_OIDC_AUDIENCE=https://api.cameleer.local
|
||||
```
|
||||
@@ -727,7 +727,7 @@ This is a new development — no production data exists. All database schemas, m
|
||||
|
||||
### Implementation Order
|
||||
|
||||
1. **Phase 1**: Update cameleer3-server (add OIDC resource server support). Deploy.
|
||||
1. **Phase 1**: Update cameleer-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