Intranet Despertares — Backend

Appearance

Creación de usuarios y relación con Cognito ​

¿Quién crea el usuario en Cognito? ​

En AWS Cognito, el login lo hace el usuario en el frontend (alias/email + contraseña). La API solo valida el JWT. Para dar de alta un usuario nuevo hay dos enfoques:

Enfoque A: Solo registrar en la BD (cognitoSub ya existe) ​

  • El usuario ya fue creado en Cognito por otro medio (consola AWS, proceso externo, invitación, etc.).
  • El admin en la intranet solo registra ese usuario en nuestra BD: ingresa cognitoSub (que obtiene de Cognito o de otro sistema), email, nombre, rol.
  • Ventaja: No hace falta que el backend tenga permisos de administrador en Cognito.
  • Desventaja: El flujo de “dar de alta un usuario” son dos pasos (crear en Cognito en algún lado + crear aquí), o el admin debe conocer el sub de Cognito.

Enfoque B: Crear en Cognito y en la BD (recomendado) ​

  • El admin en la intranet hace una sola acción: “Crear usuario” con email, nombre completo y rol.
  • El backend:
    1. Llama a Cognito (AdminCreateUser): crea el usuario en el User Pool (email como username, contraseña temporal o invitación).
    2. Opcionalmente asigna el grupo en Cognito según el rol (AdminAddUserToGroup).
    3. Obtiene el sub del usuario creado.
    4. Crea el registro en nuestra BD con ese sub, email, nombre y rol.
  • El usuario puede iniciar sesión en el frontend (con la contraseña temporal o la que defina si se envía invitación).
  • Ventaja: Un solo flujo desde el panel admin; no hace falta tocar la consola de Cognito.
  • Requisitos: Backend con AWS SDK Cognito Identity Provider y credenciales/rol con permisos cognito-idp:AdminCreateUser y cognito-idp:AdminAddUserToGroup. En el User Pool deben existir grupos con nombres iguales a los roles (ADMIN, EDITOR, TEACHER, PARENT, STUDENT).

Comportamiento en esta API ​

  • Flujo por defecto: Enfoque B. Si no se envía cognitoSub, el backend crea el usuario en Cognito y luego en la BD (requiere cognito.admin-create-enabled=true, que es el valor por defecto).

  • Crear usuario (POST /admin/users)

    • Si en el body se envía cognitoSub: se crea solo en la BD (Enfoque A; usuario ya existente en Cognito).
    • Si no se envía cognitoSub y la creación en Cognito está habilitada (cognito.admin-create-enabled=true, valor por defecto): se crea en Cognito y luego en la BD (Enfoque B).
    • Si no se envía cognitoSub y la creación en Cognito está deshabilitada: la API responde 400 indicando que debe enviarse cognitoSub o habilitar creación en Cognito.

  • Configuración (ej. application.yml):

    • cognito.admin-create-enabled: por defecto true (Enfoque B). Ponlo en false solo si quieres que el admin registre usuarios únicamente en BD con cognitoSub (Enfoque A).
    • En el User Pool de Cognito deben existir grupos con nombres exactos: ADMIN, EDITOR, TEACHER, PARENT, STUDENT (el rol se asigna con AdminAddUserToGroup).
    • El backend necesita credenciales AWS (o IAM role) con permisos cognito-idp:AdminCreateUser y cognito-idp:AdminAddUserToGroup sobre el User Pool.

  • Request (POST /admin/users) cuando se crea en Cognito (sin cognitoSub):

    • Obligatorios: email, role.
    • Opcionales: fullName, temporaryPassword (si no se envía, se genera una aleatoria).

Así, sí: el “crear” puede ir de la mano de Cognito; si quieres un único flujo desde el admin, el usuario se debe crear en Cognito (por el backend) y después en nuestra BD con el sub devuelto.