Aperçu

DTZ Identity gère trois choses : Rôles, Identités, et Authentifications pour chaque ressource qui vit à l’intérieur d’un Context. Les contexts sont les unités organisationnelles dans DTZ ; chaque entité appartient à un, et le contrôle d’accès y circule.

Diagramme de relation des entités d’identité


Concepts clés

Context

Un Context (context-…) est le conteneur pour vos applications, services et facturation. Le créateur se voit automatiquement attribuer le rôle de Context Admin, et une identité de service comme admin@{context_id}.dtz.rocks est provisionnée pour l’automatisation.

Identités

Une Identité est un principal (utilisateur humain ou compte de service). Vous lierez des affectations de rôles aux identités.

Rôles (Abstraits vs. Concrets)

  • Les rôles abstraits sont des ensembles de permissions réutilisables définis par chaque service DTZ (par ex., « containers admin », « objectstore admin », « billing admin »).
  • Les rôles concrets sont des rôles abstraits liés à un périmètre (soit un Context soit une Identité) et exprimés sous forme de URI de rôle. Ce sont ceux que vous assignez réellement.

Exemples d’URI de rôle concrets :

  • À portée Context : https://dtz.rocks/containers/admin/{context_id}
  • À portée Identité : https://dtz.rocks/identity/admin/{identity_id}

Cette séparation maintient la logique des permissions cohérente tout en rendant les affectations conscientes du contexte.


Portées des rôles

Rôles à portée d’identité

Affectent les actions sur l’identité elle‑même (par ex., qui peut définir un mot de passe ou créer des clés API pour une identité).

Exemples courants :

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

Rôles à portée de contexte

Affectent les actions au sein d’un context (déploiements, logs, stockage d’objets, etc.).

Exemples courants :

  • 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}

Chaque service DTZ peut définir ses propres noms et portées de rôles ; les URIs ci‑dessus sont représentatives.


Comment les permissions sont évaluées

  1. S’authentifier (qui vous êtes).
  2. Résoudre les rôles concrets pour l’appelant (URIs de rôle sur l’identité).
  3. Autoriser en fonction de si une URI de rôle requise correspond au périmètre cible (context ou identité) et à l’action.

Exemple : assignation et utilisation d’un rôle

  1. Assignez le rôle abstrait « containers admin » à un context spécifique → vous obtenez un rôle concret :

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

  1. Liez ce rôle à l’identité alice@example.com.
  2. Lorsque Alice appelle l’API Containers à l’intérieur de context-abc123, l’URI de rôle correspond et l’action est autorisée. Le même rôle ne confère pas de droits dans d’autres contexts.

Authentification

DTZ prend en charge plusieurs méthodes d’auth ; utilisez celle qui convient à votre client et votre environnement.

Clés API

  • Les clés sont créées dans l’interface Identity et sont scopées à un context et à une identité.
  • Envoyez-les via l’en-tête :

X-API-KEY: YOUR_API_KEY

  • Certaines intégrations tierces qui ne peuvent pas définir d’en-têtes peuvent passer apiKey en paramètre de requête (à utiliser uniquement lorsqu’inévitable).

Jetons Bearer (connexion par mot de passe)

Obtenez un JWT en POSTant le nom d’utilisateur/mot de passe, puis envoyez Authorization: Bearer ….

Demander un token :

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

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

Utiliser le token :

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

Vous pouvez aussi utiliser le JWT comme cookie nommé dtz-auth. L’authentification basique est prise en charge pour certains endpoints (apikey:apikey-1234).

Checklist de démarrage

  • Créez ou sélectionnez un Context pour votre application.
  • Décidez des rôles abstraits dont votre application a besoin et liez‑les en rôles concrets aux bonnes portées (Context vs. Identité).
  • Assignez ces rôles concrets aux identités (utilisateurs/comptes de service) qui en ont besoin.