# Autenticación de la POC sin Keycloak

El perfil explícito `demo-token` usa un token fijo en `Authorization: Bearer ...`.
No necesita un JWT, issuer, audiencia ni JWKS de Keycloak. El resto de las rutas
sigue protegido; sin token o con un valor incorrecto responde 401.

El override `compose.mock.yaml` activa `postgres96,demo-mock,demo-token` por defecto.
Para usarlo basta el `MOCK_ADMIN_TOKEN` existente (al menos 32 caracteres base64url:
letras, números, guion o guion bajo). Compose lo reutiliza como token del
orquestador si no defines `ORCHESTRATOR_DEMO_TOKEN`.

Opcionalmente, separar tokens en `.env`:

```dotenv
# Sustituir por un token aleatorio de 32 a 256 caracteres base64url.
ORCHESTRATOR_DEMO_TOKEN=
ORCHESTRATOR_DEMO_SUBJECT=poc-user
ORCHESTRATOR_DEMO_SCOPE=demo
ADMIN_BUSINESS_SCOPES=demo
```

Un valor vacío de ORCHESTRATOR_DEMO_TOKEN en Compose usa MOCK_ADMIN_TOKEN. Al
arrancar directamente con Java y demo-token, ORCHESTRATOR_DEMO_TOKEN es obligatorio.
No guardar tokens reales en el repositorio ni en las colecciones exportadas.

Aplicar la configuración y reconstruir el servicio:

```bash
docker compose -f compose.yaml -f compose.mock.yaml up -d --build orquestador
docker compose -f compose.yaml -f compose.mock.yaml exec orquestador printenv SPRING_PROFILES_ACTIVE
```

En la colección Postman **Orquestador NMP**, establecer `accessToken` con ese
token fijo, sin escribir Bearer. Dejar vacíos `editorToken`, `publisherToken`,
`adminToken` y `operatorToken` para que reutilicen accessToken. Borrar valores
antiguos de esos campos y de variables de entorno de Postman que los sobrescriban.
La colección del mock mantiene `mockAdminToken=MOCK_ADMIN_TOKEN`.

## Identidad y permisos

El servidor asocia el token a `poc-user`, ámbito `demo`, y roles ANALISTA,
FLOW_EDITOR, FLOW_PUBLISHER, FLOW_ADMIN y EXECUTION_OPERATOR. Subject y ámbito
se pueden configurar con las variables indicadas; roles fijos para la demo.
El cliente no puede escoger identidad/roles mediante el cuerpo o cabeceras.

Todas las personas que usen el mismo token son el mismo usuario de POC. Las
solicitudes creadas con otro subject o ámbito (incluido el usuario previo de
Keycloak) no se vuelven accesibles automáticamente. Cambiar el token conservando
subject y ámbito permite seguir trabajando con las solicitudes de la POC.

Se conservan las comprobaciones de propiedad, ámbito, roles, If-Match,
idempotencia y el rol restringido de PostgreSQL. La administración exige que
ADMIN_BUSINESS_SCOPES incluya el ámbito configurado. Un valor previo en `.env`
no se reemplaza automáticamente por demo.

FLOW_ADMIN_ENABLED, REQUEST_API_ENABLED y WORKER_ENABLED siguen siendo
interruptores independientes. Para el recorrido completo habilitarlos y usar
credenciales DB de runtime restringidas y migración separadas según SECURITY.md.
El token no crea tipos, flujos ni solicitudes y no evita esa comprobación DB.

## Modo normal

Sin `demo-token`, continúa la validación RS256, issuer, audiencia, expiración y
claims del JWT. JWT_ISSUER_URI, JWT_JWK_SET_URI y JWT_AUDIENCE son obligatorios
al arrancar la aplicación en modo normal, aunque Compose permita valores vacíos
para poder combinarlo con el override de POC. Configurar un token fijo sin
activar el perfil no habilita este modo.

Internamente se adapta la identidad a la representación usada por los
controladores existentes. No se firma un JWT ni se confía en claims proporcionados
por el cliente; únicamente se compara el secreto configurado. No hay caducidad
automática del token fijo: rotarlo requiere recrear el servicio. Esta POC usa
HTTP sin cifrado conforme a la configuración de demo solicitada.