# Authentication, Authorization, and Publishing Security Model

## Trust boundaries

Slice 7a introduces three principals: anonymous visitors, authenticated users, and authenticated admins. Authentication establishes a provider-neutral principal; authorization independently checks capabilities derived from the principal's current database role and enabled state.

The authoring API and published runtime are separate trust boundaries:

- Admin authoring may submit canonical project/action definitions to validation and test-execution endpoints.
- Published clients never submit action definitions. They submit only runtime values to an action ID inside an immutable server-owned snapshot.
- Users and anonymous visitors never receive draft project JSON, secret metadata, admin publication metadata, password/session material, or editor APIs.

## Primary threats and controls

| Threat | Required control |
|---|---|
| Password theft | `scrypt` password hashes with unique salts; no plaintext storage/logging; generic login failures |
| Brute force | Per-identifier/address bounded login throttling and retry response |
| Session theft/fixation | Random opaque server-side sessions, hashed identifiers at rest, rotation at login/role changes, secure cookie attributes |
| CSRF | Per-session CSRF token plus same-origin/custom-header verification on cookie-authenticated mutations |
| Disabled or demoted account retaining access | Resolve enabled user and current role for each session; revoke all sessions on disable, password reset, or role change |
| User reaching authoring APIs | Central admin middleware on projects, validation, secrets, history mutation, authoring proxy, user administration, and publication management |
| Draft information disclosure | Separate public runtime DTO from admin publication DTO; never return source project or snapshot through public catalog routes |
| Public app invoking stored credentials | Reject publication when a public snapshot contains any non-anonymous action |
| Browser substituting URL/auth/secret | Published route resolves the action exclusively from the stored snapshot and accepts only referenced runtime values |
| Published template injection | Allow only declared component/variable template tokens and JSON-compatible bounded runtime values; apply existing proxy validation afterward |
| Sensitive logging | Redact passwords, cookies, session/CSRF values, credential material, and future identity-provider tokens from responses, logs, and history |
| Unsafe bootstrap | Create first admin only through explicit non-default operator input; never log credentials; refuse once an admin exists unless recovery flow applies |

## Route policy

- Public: health, login, public catalog/runtime, public published action execution.
- Authenticated: current principal, logout, authenticated catalog/runtime and execution.
- Admin: every authoring, project, validation, secret, execution-history management, user-management, and publication-management route.

The backend—not frontend navigation—is the authorization authority.

## Published snapshot rules

Publishing validates and stores a canonical JSON snapshot transactionally. Draft saves do not mutate it. Republish validates the replacement before atomically increasing the publication version. Unpublish disables runtime access without deleting the source project.

Active publications block source-project deletion. Public snapshots must contain only anonymous actions. Authenticated snapshots may contain server-side secret references, but public/runtime representations never return those references.

## OIDC readiness

Sessions refer to a stable local user and provider-neutral principal. User records reserve provider/subject identity linkage, while authorization consumes only local user ID, enabled state, and role. Slice 9 can therefore exchange a validated OIDC identity for the same Conductor session without changing RBAC or publication visibility.