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.

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
- S’authentifier (qui vous êtes).
- Résoudre les rôles concrets pour l’appelant (URIs de rôle sur l’identité).
- 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
- Assignez le rôle abstrait « containers admin » à un context spécifique → vous obtenez un rôle concret :
https://dtz.rocks/containers/admin/context-abc123
- Liez ce rôle à l’identité
alice@example.com. - 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
apiKeyen 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.