Resumen

DTZ Identity gestiona tres cosas: Roles, Identidades, y Autenticaciones para cada recurso que vive dentro de un Contexto. Los contextos son las unidades organizativas en DTZ; cada entidad pertenece a uno, y el control de acceso fluye a través de él.

Diagrama de relaciones de entidades de identidad

Conceptos clave

Contexto

Un Contexto (context-…) es el contenedor para tus aplicaciones, servicios y facturación. Al creador se le asigna automáticamente Context Admin, y se aprovisiona una identidad de servicio como admin@{context_id}.dtz.rocks para la automatización.

Identidades

Una Identidad es un principal (usuario humano o cuenta de servicio). Vincularás asignaciones de roles a identidades.

Roles (Abstractos vs. Concretos)

  • Roles abstractos son conjuntos de permisos reutilizables definidos por cada servicio DTZ (p. ej., “containers admin”, “objectstore admin”, “billing admin”).
  • Roles concretos son roles abstractos vinculados a un ámbito (ya sea un Contexto o una Identidad) y expresados como una URI de rol. Estos son los que realmente asignas.

Ejemplos de URIs de roles concretos:

  • Con ámbito de contexto: https://dtz.rocks/containers/admin/{context_id}
  • Con ámbito de identidad: https://dtz.rocks/identity/admin/{identity_id}

Esta separación mantiene la lógica de permisos consistente mientras hace que las asignaciones sean conscientes del contexto.

Ámbitos de roles

Roles con alcance en la identidad

Afectan acciones sobre la propia identidad (p. ej., quién puede establecer una contraseña o crear claves API para una identidad).

Ejemplos comunes:

  • https://dtz.rocks/identity/admin/{identity_id}
  • https://dtz.rocks/billing/admin/{identity_id}
  • https://dtz.rocks/identity/assume/{identity_id}

Roles con alcance en el contexto

Afectan acciones dentro de un contexto (despliegues, registros, almacenamiento de objetos, etc.).

Ejemplos comunes:

  • https://dtz.rocks/context/admin/{context_id}
  • https://dtz.rocks/containers/admin/{context_id}
  • https://dtz.rocks/objectstore/admin/{context_id}
  • https://dtz.rocks/observability/admin/{context_id}
  • https://dtz.rocks/containerregistry/admin/{context_id}
  • https://dtz.rocks/rss2email/admin/{context_id}

Cada servicio de DTZ puede definir sus propios nombres y ámbitos de rol; las URIs anteriores son representativas.

Cómo se evalúan los permisos

  1. Autenticar (quién eres).
  2. Resolver roles concretos para el llamador (URIs de roles en la identidad).
  3. Autorizar en función de si un URI de rol requerido coincide con el ámbito objetivo (contexto o identidad) y la acción.

Ejemplo: asignar y usar un rol

  1. Asigna el rol abstracto “containers admin” a un contexto específico → obtendrás un rol concreto:

https://dtz.rocks/containers/admin/context-abc123

  1. Vincula ese rol a la identidad alice@example.com.
  2. Cuando Alice llama a la API de Containers dentro de context-abc123, el URI de rol coincide y la acción está autorizada. El mismo rol no concede derechos en otros contextos.

Autenticación

DTZ admite múltiples métodos de autenticación; usa el que se adapte a tu cliente y entorno.

Claves API

  • Las claves se crean en la interfaz de Identity y están vinculadas a un contexto y una identidad.
  • Envíalas mediante el encabezado:

X-API-KEY: YOUR_API_KEY

  • Algunas integraciones de terceros que no pueden establecer encabezados pueden pasar apiKey como parámetro de consulta (úsalo solo cuando sea inevitable).

Tokens Bearer (inicio de sesión con contraseña)

Obtén un JWT haciendo POST con nombre de usuario/contraseña, luego envía Authorization: Bearer ….

Solicitar token:

POST https://identity.dtz.rocks/api/2021-02-21/token/auth
Content-Type: application/json

{
"username": "user",
"password": "password"
}

Usar token:

curl -H "Authorization: Bearer eyJhb..." \
  https://identity.dtz.rocks/api/2021-02-21/me

También puedes usar el JWT como una cookie llamada dtz-auth. La autenticación básica está soportada para algunos endpoints (apikey:apikey-1234).

Lista de verificación para empezar

  • Crea o selecciona un Contexto para tu aplicación.
  • Decide qué roles abstractos necesita tu aplicación y vincúlalos como roles concretos en los ámbitos correctos (Contexto vs. Identidad).
  • Asigna esos roles concretos a las identidades (usuarios/cuentas de servicio) que los necesiten.