Saltar a contenido

Identity

Servicio de gestion de identidad y acceso de Camunda 8. Implementado como frontend React sin backend separado (la logica vive en modulos authentication/ y security/ del monorepo). Soporta OIDC generico via Spring Security, sin dependencia de Keycloak.

Contexto

Identity centraliza la gestion de quien puede acceder a que dentro del ecosistema Camunda. Es el punto unico para administrar usuarios, grupos, roles, tenants y reglas de autorizacion que aplican transversalmente a todos los componentes: entities/zeebe-gateway, entities/operate, entities/tasklist y entities/optimize.

Arquitectura: React frontend sin backend separado

A diferencia de lo que podria esperarse de un servicio IAM, Identity no tiene un backend independiente:

  • El frontend es una aplicacion React que se sirve como parte de la webapp unificada de Camunda
  • La logica de autenticacion y autorizacion vive en los modulos authentication/ y security/ del monorepo Java
  • Estos modulos se integran como librerias en cada componente (Operate, Tasklist, etc.) via Spring Security
  • No hay un proceso/servicio separado que manejar — la logica se distribuye embebida en los demas servicios

Sin dependencia de Keycloak

En versiones anteriores, Camunda dependia de Keycloak como Identity Provider. La arquitectura actual:

  • Usa OIDC generico (OpenID Connect) via Spring Security OAuth2
  • Compatible con cualquier Identity Provider que implemente OIDC: Keycloak, Auth0, Azure AD, Okta, Google, etc.
  • La configuracion se hace via propiedades Spring estandar (spring.security.oauth2.*)
  • Ver concepts/authentication-flow para el flujo detallado

Gestion de entidades

Identity administra las siguientes entidades:

Users

  • Representacion interna de usuarios autenticados
  • Mapeados desde claims del token OIDC (subject, email, preferred_username)
  • No almacena credenciales — la autenticacion es delegada al IdP externo

Groups

  • Agrupacion logica de usuarios para asignacion colectiva de permisos
  • Usados como candidateGroups en user tasks de entities/tasklist
  • Pueden mapearse desde claims del token o gestionarse directamente

Roles

  • Conjuntos de permisos predefinidos (ej: admin, operator, viewer)
  • Se asignan a usuarios o grupos
  • Definen que operaciones puede ejecutar cada usuario en cada componente

Tenants

  • Soporte para concepts/multi-tenancy: aislamiento logico de datos entre organizaciones
  • Cada tenant tiene su propio espacio de procesos, instancias y tasks
  • Los usuarios se asocian a uno o mas tenants

Mapping Rules

  • Reglas que mapean claims del token OIDC a roles, grupos o tenants internos
  • Permiten automatizar la asignacion de permisos basandose en la informacion del IdP
  • Ejemplo: claim department=engineering → grupo engineers

Authorizations

  • Permisos granulares sobre recursos especificos (ver concepts/authorization-model)
  • Modelo RBAC: usuario/grupo + rol + recurso → permitir/denegar
  • Recursos tipicos: definiciones de proceso, instancias, decisiones, tasks

Multi-IdP support

Identity soporta configuracion con multiples Identity Providers:

  • Un IdP primario para autenticacion
  • Federacion de identidades para escenarios enterprise
  • Mappings especificos por IdP para normalizar claims

Relaciones

Abierto / gaps

  • Modelo de cache de permisos para evitar validaciones repetidas contra el IdP
  • Soporte para service accounts (M2M tokens) y sus permisos
  • Estrategia de migracion desde Keycloak al modelo OIDC generico