Aperçu

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

Diagramme des relations d’entités d’identité

Concepts clés

Contexte

Un Contexte (context-…) est le conteneur pour vos applications, services et facturation. Le créateur se voit automatiquement attribuer le rôle Administrateur du Contexte, 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 les 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 (ex. : « administrateur containers », « administrateur objectstore », « administrateur facturation »).
  • Les rôles concrets sont des rôles abstraits liés à un périmètre (soit un Contexte ou une Identité) et exprimés sous la forme d’un URI de rôle. Ce sont ceux que vous attribuez réellement.

Exemples d’URI de rôles concrets :

  • Périmètre Contexte : https://dtz.rocks/containers/admin/{context_id}
  • Périmètre Identité : https://dtz.rocks/identity/admin/{identity_id}

Cette séparation maintient la cohérence de la logique des permissions tout en rendant les affectations sensibles au contexte.

Périmètres des rôles

Rôles à périmètre Identité

Impactent les actions sur l’identité elle-même (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 à périmètre Contexte

Impactent les actions dans un contexte (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 de rôles et périmètres ; les URI ci-dessus sont représentatifs.

Évaluation des permissions

  1. Authentifier (qui vous êtes).
  2. Résoudre les rôles concrets pour l’appelant (URI de rôles liés à l’identité).
  3. Autoriser si un URI de rôle requis correspond au périmètre ciblé (contexte ou identité) et à l’action.

Exemple : attribution et utilisation d’un rôle

  1. Attribuez le rôle abstrait « administrateur containers » à un contexte 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. Quand Alice appelle l’API Containers dans context-abc123, l’URI du rôle correspond et l’action est autorisée. Le même rôle ne donne pas de droits dans d’autres contextes.

Authentification

DTZ supporte plusieurs méthodes d’authentification ; utilisez celle qui convient à votre client et à votre environnement.

Clés API

  • Les clés sont créées dans l’interface utilisateur d’Identité et sont limitées à un contexte et à une identité.
  • À envoyer via l’en-tête :

X-API-KEY: VOTRE_CLE_API

  • Certaines intégrations tierces qui ne peuvent pas définir les en-têtes peuvent transmettre apiKey en paramètre de requête (à utiliser uniquement si 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 ….

Requête du jeton :

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

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

Utilisation du jeton :

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 supportée pour certains endpoints (apikey:apikey-1234).

Checklist de démarrage

  • Créez ou sélectionnez un Contexte pour votre application.
  • Décidez quels rôles abstraits votre application nécessite et liez-les en rôles concrets avec les périmètres appropriés (Contexte vs. Identité).
  • Attribuez ces rôles concrets aux identités (utilisateurs/comptes de service) qui en ont besoin.