Groupes et accès aux apps

Créer des groupes, gérer les membres, restreindre les applications par groupe, et piloter la MFA, la politique de mot de passe et le claim groups des jetons.

Les groupes sont l'unité de gestion des accès dans l'annuaire : ils décident à quelles applications un utilisateur peut se connecter, quels utilisateurs doivent utiliser la MFA, et ce qui apparaît dans le claim groups des jetons et des assertions SAML.

Comment fonctionnent les groupes

Un groupe est un ensemble plat et nommé d'utilisateurs de votre organisation : un nom, une description optionnelle, un indicateur optionnel « MFA obligatoire », et des membres. La gestion des groupes exige la permission correspondante ; chaque mutation est auditée (événements admin.group.*).

curl -sS -X POST https://accounts.obexal.com/v1/admin/groups \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"name":"Finance","description":"Equipe finance","requireMfa":false}'
# 201 -> {"group":{"id":"<groupId>","name":"Finance","description":"Equipe finance","requireMfa":false,"memberCount":0}}

GET /v1/admin/groups liste les groupes, PUT /v1/admin/groups/{id} en met un à jour, DELETE /v1/admin/groups/{id} le supprime avec ses appartenances et ses assignations d'applications.

Gérer les membres

Les membres s'ajoutent et se retirent individuellement, par identifiant d'utilisateur :

curl -sS -X POST https://accounts.obexal.com/v1/admin/groups/<groupId>/members \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"userId":"<userId>"}'
# 200 -> {"status":"ok"}

GET /v1/admin/groups/{id}/members renvoie les membres (id et e-mail) ; DELETE /v1/admin/groups/{id}/members/{userId} en retire un. L'utilisateur doit déjà exister dans l'annuaire : créez les comptes par invitation ou par SCIM entrant.

Restreindre une application à des groupes

Par défaut, une application sans aucun groupe assigné est ouverte à tous les utilisateurs de l'organisation (les applications existantes continuent de fonctionner quand vous adoptez les groupes). Dès qu'au moins un groupe est assigné, l'application est restreinte : seuls les membres d'un groupe assigné peuvent s'y connecter.

curl -sS -X POST https://accounts.obexal.com/v1/admin/groups/<groupId>/apps \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"clientId":"app_a1b2c3"}'
# 200 -> {"status":"ok"}

Le contrôle s'exécute à l'émission du code d'autorisation OIDC : un utilisateur hors des groupes assignés reçoit une erreur OAuth access_denied et aucun code n'est créé. Le portail employé suit le même modèle : GET /v1/me/apps (la page « Mes applications ») liste exactement les applications assignées via les groupes de l'utilisateur, avec le groupe qui donne chaque accès.

Le claim groups

Quand un utilisateur appartient à au moins un groupe, l'id_token porte un claim groups avec les noms des groupes (aucun scope supplémentaire requis ; le claim est omis si l'utilisateur n'a aucun groupe) :

{
  "sub": "u_7f3a9c",
  "aud": "app_a1b2c3",
  "email": "alice@example.eu",
  "groups": ["Finance", "Managers"]
}

Les assertions SAML émises par Obexal en IdP portent les mêmes noms dans l'attribut eduPersonAffiliation. Le claim n'apparaît ni dans les access tokens ni dans la réponse userinfo. Comme le claim porte des noms, renommer un groupe change ce que reçoivent les applications aval.

Politiques par groupe

Deux politiques de connexion sont pilotées par les groupes :

• MFA obligatoire : posez "requireMfa": true sur un groupe et chaque membre doit valider la MFA à la connexion, en plus d'un éventuel mandat MFA de toute l'organisation.
• Dérogations de politique de mot de passe : un groupe peut porter une politique de mot de passe plus stricte que celle de l'organisation. GET /v1/admin/password-policy/groups liste les dérogations, PUT /v1/admin/password-policy/groups/{groupId} en pose une, DELETE la retire. Quand un utilisateur appartient à plusieurs groupes, la valeur la plus stricte l'emporte champ par champ ; une dérogation ne peut que durcir la politique du tenant, jamais l'affaiblir.

Limites

• Pas de groupes imbriqués : un groupe contient des utilisateurs, jamais d'autres groupes.
• Les appartenances aux groupes ne sont pas gérables via SCIM (le serveur entrant est limité aux Users).
• L'assignation d'application se fait par client_id OAuth, une application à la fois.