Hiérarchie de l’organisation
Une instance contient des organisations de niveau supérieur. Une organisation peut contenir un niveau de sous-organisation ; chaque organisation reste une frontière de politique, d’adhésion, de marque, de RBAC et d’isolement.
Une OrgUnit est un département ou une équipe au sein d’une organisation. Cela ne modifie jamais TenantContext, l’émetteur, les revendications de jeton ou la limite SubOrg à un niveau.
- Les arborescences OrgUnit prennent en charge une profondeur maximale de huit.
- Chaque membre peut avoir une OrgUnit principale et des emplacements supplémentaires.
- Le responsable actif le plus proche dans la chaîne d’ancêtres de l’OrgUnit est le premier candidat approbateur de demande d’accès.
Projets et politique d’accès
Les projets regroupent les applications et les rôles d’autorisation. La access_policy par projet contrôle uniquement les utilisateurs de la même organisation sans UserGrant effectif ; L’autorisation ProjectGrant inter-organisations n’est pas affectée.
| Politique du projet | Comportement dans la même organisation | Parcours libre-service |
|---|---|---|
| Ouvrir | Autorisé sans UserGrant. | Aucune demande d’accès n’est nécessaire. |
| Limité | Refusé; un administrateur accorde l’accès directement. | Aucune demande en libre-service n’est disponible. |
| Approbation requise | Refusé jusqu’à ce qu’une AccessRequest soit approuvée. | L’utilisateur soumet une demande d’accès. |
Cycle de vie des demandes d’accès
AccessRequest passe de en attente à approuvé, refusé, annulé ou expiré. Chaque résultat est terminal et les demandes en attente expirent paresseusement après 14 jours.
L’approbation crée un UserGrant traçable dans la même transaction. Le demandeur ne peut pas approuver sa propre demande ; la résolution passe du responsable de l’OrgUnit aux chefs de projet et d’organisation.
| Méthode | Chemin | Objectif | Portée requise |
|---|---|---|---|
GET, POST |
/auth/access-requests |
Créez et répertoriez les demandes de l’utilisateur actuel. | session |
POST |
/auth/access-requests/:id/cancel |
Annulez la demande en attente de l’utilisateur actuel. | session |
GET |
/auth/access-approvals |
Répertoriez les demandes en attente de l’approbation de l’utilisateur actuel. | session |
POST |
/auth/access-approvals/:id/{approve|deny} |
Approuver ou refuser une demande en attente attribuée à l’utilisateur actuel. | session |
GET |
/v1/organizations/:orgId/access-requests |
Répertoriez les demandes au sein d’une organisation. | access-requests:read |
GET |
/v1/organizations/:orgId/units |
Lisez l’arborescence des unités d’organisation. | org-units:read |
POST, PATCH, DELETE, PUT |
/v1/organizations/:orgId/units/* |
Créez, mettez à jour, déplacez, archivez et gérez les membres des unités. | org-units:write |
Limites de sécurité
- Chaque requête OrgUnit et AccessRequest est limitée à
tenant_idetorg_id. Les identifiants inter-organisations ou inter-locataires renvoient 404 sans révéler leur existence. - L’adhésion et l’accès au projet sont distincts : les invitations rejoignent une organisation, tandis que AccessRequest accorde à un membre actif existant l’accès à un projet.
- SCIM provisionne les utilisateurs et les adhésions, mais ne mappe pas les groupes d’annuaire aux OrgUnits ou aux rôles de projet dans l’implémentation actuelle.
- L’API de gestion utilise la pagination du curseur et les gardes de clé API partagée ou de gestionnaire d’organisation. Il ne réutilise pas les itinéraires commerciaux des utilisateurs finaux.