Fédération d'identité

Disponible dans l’édition autonome depuis la version 1.78.0.

Vos équipes peuvent se connecter avec les comptes qu’elles ont déjà. Le fournisseur d’identité d’AarView reste en place comme intermédiaire : il envoie l’utilisateur vers votre IdP (OpenID Connect, code d’autorisation avec PKCE), vérifie la réponse et ouvre à AarView sa session habituelle. Les comptes locaux (akadmin compris) continuent de fonctionner. SAML n’est pas pris en charge.

1. Déclarez AarView chez votre IdP comme application web (client confidentiel), avec cette URI de redirection :

https://<AARVIEW_DOMAIN>/source/oauth/callback/sso/

• Microsoft Entra ID : Inscriptions d’applications > Nouvelle inscription, plateforme Web, l’URI ci-dessus. Certificats et secrets > Nouveau secret client. Configuration des jetons > Ajouter une revendication de groupes > Groupes de sécurité (ou Groupes attribués à l’application, qui évite la limite de 200 groupes), dans le jeton d’ID : la revendication contient les identifiants d’objet des groupes. Revendications facultatives > jeton d’ID : email. Notez l’identifiant du locataire (Vue d’ensemble).
• Okta : Applications > Create App Integration > OIDC > Web Application, l’URI ci-dessus en redirection de connexion, type d’octroi Authorization Code. Sign On > OpenID Connect ID Token > Groups claim type Filter, nom groups (par exemple Matches regex .*, ou seulement vos groupes SOC). Affectez les personnes ou les groupes à l’application.
• Tout fournisseur OpenID Connect (Keycloak, Authentik, ADFS 2019 et suivants, Google Workspace…) : un client confidentiel, l’URI ci-dessus et une revendication groups dans l’id_token (ou une autre, voir AARVIEW_FEDERATION_GROUPS_CLAIM).

2. Renseignez .env et relancez ./install.sh :

Réglage	Valeur
AARVIEW_FEDERATION	entra, okta ou oidc
AARVIEW_FEDERATION_ISSUER	Entra : https://login.microsoftonline.com/<id du locataire>/v2.0 (jamais common ni organizations, qui acceptent n’importe quel locataire). Okta : https://<org>.okta.com ou https://<org>.okta.com/oauth2/<id du serveur>
AARVIEW_FEDERATION_CLIENT_ID, AARVIEW_FEDERATION_CLIENT_SECRET	ceux de l’inscription
AARVIEW_FEDERATION_GROUP_MAP	<groupe IdP>=<rôle> séparés par ;, rôle super_admin, admin ou analyst. Entra : identifiants d’objet ; Okta : noms de groupes
AARVIEW_FEDERATION_MFA	authentik (par défaut) ou idp, voir plus bas

Facultatifs : AARVIEW_FEDERATION_NAME (libellé du bouton), AARVIEW_FEDERATION_GROUPS_CLAIM (roles pour les rôles d’application Entra), AARVIEW_FEDERATION_SCOPES (groups par défaut pour Okta), AARVIEW_FEDERATION_TOKEN_AUTH (post_body pour Entra, basic_auth sinon), AARVIEW_FEDERATION_CA_CERT (/certs/<fichier>, pour un IdP signé par une autorité privée). L’installateur vérifie chaque valeur avant la construction, lit le document de découverte de votre IdP et s’arrête si l’émetteur publié n’est pas exactement celui que vous avez indiqué. Videz AARVIEW_FEDERATION et relancez : le bouton disparaît.

Qui entre, avec quel rôle. Refus par défaut : une personne qui n’est dans aucun des groupes déclarés est refusée par l’intermédiaire et n’obtient aucun compte. Une personne déclarée reçoit le rôle le plus élevé parmi ses groupes, dans votre propre locataire (AARVIEW_OPERATOR_TENANT) ; le rôle est relu à chaque connexion, donc déplacer quelqu’un d’un groupe à l’autre chez votre IdP prend effet à sa connexion suivante. Une personne retirée de tous les groupes déclarés ne peut plus se connecter ; une session déjà ouverte se termine dans les limites de session d’AarView (30 minutes d’inactivité, 8 heures). Les noms de groupes de votre IdP ne sont jamais recopiés : un groupe nommé « authentik Admins » ou « aarview-super-admin » chez votre IdP ne signifie rien, et aucune correspondance ne peut viser un groupe d’administration du fournisseur d’identité. Les comptes fédérés sont toujours ceux de votre équipe ; les comptes des clients restent locaux.

Les comptes sont rapprochés par l’identifiant du sujet chez l’IdP (sub), jamais par l’adresse électronique ni par le nom d’utilisateur. Une adresse dans un id_token ne prouve pas, chez tous les IdP, que la personne la possède, et s’y fier permettrait à un compte de l’IdP de prendre la main sur un compte local (celui de l’administrateur, par exemple). Si un compte local a déjà le même nom d’utilisateur ou la même adresse qu’une personne fédérée, celle-ci est refusée tant que vous n’avez pas supprimé ou renommé le compte local : une personne, un compte.

Second facteur. AARVIEW_FEDERATION_MFA=authentik (par défaut) : les utilisateurs fédérés enrôlent aussi le second facteur d’AarView (TOTP) à leur première connexion, quoi qu’ait fait votre IdP. idp : AarView fait confiance à la double authentification de votre IdP, mais seulement si l’id_token signé la prouve : amr contient mfa, ou deux types de facteur (par exemple pwd et otp), ou acr fait partie de AARVIEW_FEDERATION_MFA_ACR. Sans cette preuve, la connexion est refusée, jamais laissée passer. Okta place amr dans ses id_tokens. Pour Entra, vérifiez que vos jetons le portent avant de choisir idp ; sinon, gardez authentik.

Chaque id_token est vérifié (signature avec les clés publiées par l’IdP, audience, émetteur exact, expiration), et son sujet doit être celui renvoyé par userinfo. Les refus sont journalisés avec leur motif : docker compose logs authentik-server | grep aarview-federation.

Bon à savoir : une première connexion abandonnée pendant l’enrôlement du second facteur est reprise à la tentative suivante par le même sujet de l’IdP, jamais par quelqu’un d’autre. Les comptes fédérés n’ont pas de mot de passe AarView : les écrans protégés par mot de passe (changer son propre facteur) ne les concernent pas, et un administrateur réinitialise un facteur perdu. Une autorité privée pour votre IdP (AARVIEW_FEDERATION_CA_CERT) doit porter l’extension keyUsage (keyCertSign) : la pile TLS du fournisseur d’identité refuse une autorité qui en est dépourvue.

Ce qui a été testé, ce qui ne l’a pas été. Le banc de test de la fédération déroule tout le parcours du navigateur face à un fournisseur OIDC de test local (TLS, PKCE) et vérifie des identités déclarées, non déclarées et hostiles (55 contrôles). Rien n’a été testé contre de vrais locataires Entra ID ou Okta : les étapes d’inscription ci-dessus suivent leur documentation, et la première connexion chez vous en est la vraie vérification.