Identité et IAM, les notions de base

La gestion des identités et des accès (IAM, pour Identity and Access Management) répond à deux questions : qui est la personne ou le programme qui se présente, et que peut-il faire. Keycloak est un outil d’IAM. Avant d’apprendre comment il fonctionne, il faut maîtriser le vocabulaire commun à tous les produits du domaine. Ce cours le pose, sans parler encore de Keycloak.

L’identité numérique

Une identité numérique est la représentation d’une personne, ou d’un programme, dans un système informatique. Elle tient en trois éléments :

• un identifiant unique et stable : un login, une adresse e-mail, un numéro d’agent ;
• des attributs qui la décrivent : nom, prénom, service, date d’arrivée ;
• des moyens d’authentification associés : mot de passe, application d’OTP, clé de sécurité.

On parle de compte pour l’enregistrement de cette identité dans un système donné. Une même personne peut avoir plusieurs comptes : un dans l’annuaire de l’entreprise, un dans l’outil de paie, un sur un portail partenaire. Tout l’enjeu de l’IAM est de relier ces comptes à une identité unique et de limiter leur nombre.

Les identités ne sont pas toutes humaines. Un traitement de nuit qui appelle une API a lui aussi besoin d’une identité, souvent appelée compte de service. Il s’authentifie avec un secret ou une clé, jamais avec un mot de passe saisi par quelqu’un.

Authentification et autorisation

Ces deux mots sont souvent confondus. Ils désignent deux étapes distinctes.

	Authentification	Autorisation
Question	Qui êtes-vous ?	Avez-vous le droit ?
Moment	À la connexion	À chaque action
Entrée	Mot de passe, OTP, clé FIDO2	Rôles, groupes, attributs, règles
Sortie	Une identité vérifiée	Accès accordé ou refusé
Exemple	Saisir son mot de passe	Voir le bouton « Valider la facture »

L’authentification précède toujours l’autorisation. Un utilisateur parfaitement authentifié peut se voir refuser une action. À l’inverse, accorder un droit à une identité mal vérifiée n’a aucune valeur.

Les trois acteurs : utilisateur, fournisseur d’identité, application

Dans une architecture moderne, l’application ne vérifie plus elle-même les mots de passe. Elle délègue cette tâche à un composant spécialisé.

• Le fournisseur d’identité (IdP, Identity Provider) authentifie l’utilisateur et atteste de son identité. Keycloak joue ce rôle.
• Le fournisseur de service (SP, Service Provider) est l’application qui fait confiance à l’IdP. Le terme vient de SAML ; en OAuth 2.0 et OpenID Connect, on parle de client ou de Relying Party (partie qui fait confiance).
• L’utilisateur passe de l’un à l’autre, généralement via son navigateur.

Ce découpage a trois avantages. Les mots de passe ne sont saisis qu’à un seul endroit. Les règles de sécurité (MFA, verrouillage) sont appliquées une seule fois. Les applications n’ont plus de base de comptes à maintenir.

Le vocabulaire des échanges : jeton, assertion, session

Trois mots reviennent dans tous les cours suivants.

• Jeton (token) : un message que l’IdP émet et que l’application peut vérifier. En OpenID Connect, il s’agit le plus souvent d’un JWT (JSON Web Token), une structure JSON signée.
• Assertion : l’équivalent SAML. C’est un document XML signé par l’IdP qui affirme « cet utilisateur s’est authentifié à telle heure, voici ses attributs ».
• Session : l’état qui mémorise qu’un utilisateur est connecté. Il en existe au moins deux : la session chez l’IdP et la session locale dans chaque application.

Voici à quoi ressemble le contenu (décodé) d’un jeton :

{
  "iss": "https://idp.exemple.fr",
  "sub": "8f3c2a10-5d4e-4b7a-9c1f-2e6d7a8b9c0d",
  "aud": "portail-rh",
  "exp": 1762354800,
  "iat": 1762354500,
  "name": "Claire Martin",
  "email": "claire.martin@exemple.fr"
}

On y lit l’émetteur (iss), l’identifiant stable de l’utilisateur (sub), l’application destinataire (aud), la date d’émission (iat) et la date d’expiration (exp), puis des attributs. Ces champs s’appellent des claims. Le cours suivant les détaille.

Le SSO

L’authentification unique (SSO, Single Sign-On) permet de se connecter une fois et d’accéder ensuite à plusieurs applications sans ressaisir ses identifiants. Le mécanisme est simple : lors de la première connexion, l’IdP ouvre une session et dépose un cookie dans le navigateur. Quand une seconde application redirige l’utilisateur vers l’IdP, celui-ci reconnaît la session et émet un nouveau jeton immédiatement, sans rien demander.

Le SSO a un corollaire plus difficile : la déconnexion unique (SLO, Single Logout). Fermer la session de l’IdP ne ferme pas automatiquement les sessions locales des applications. Il faut que l’IdP les prévienne, et que chaque application sache traiter ce message. En pratique, c’est l’un des points les plus fragiles d’une intégration.

La fédération d’identité

La fédération étend la confiance au-delà d’une seule organisation. Deux domaines conviennent que l’un accepte les identités authentifiées par l’autre. Les exemples sont courants :

• un portail public accepte les comptes FranceConnect ;
• une entreprise permet à ses partenaires de se connecter avec le compte de leur propre société ;
• un IdP central délègue l’authentification des agents à l’Active Directory d’un ministère.

Dans tous les cas, l’IdP de l’autre domaine authentifie l’utilisateur et transmet un jeton ou une assertion. Votre IdP le vérifie (signature, émetteur, validité) puis relie cette identité externe à un compte local, ou en crée un. Le mot de passe de l’utilisateur ne sort jamais de son domaine d’origine.

Ne confondez pas fédération et synchronisation. Synchroniser, c’est copier des comptes d’un annuaire à un autre. Fédérer, c’est faire confiance à l’authentification réalisée ailleurs.

Le cycle de vie des comptes

Une identité n’est pas figée. Elle suit un cycle de vie que l’IAM doit outiller de bout en bout.

Étape	Exemples d’actions
Arrivée	Création du compte, attribution des droits initiaux, envoi d’un lien d’activation
Activation	Choix du mot de passe, vérification de l’e-mail, enrôlement d’un second facteur
Mobilité	Changement de service, ajout et retrait de rôles
Suspension	Désactivation temporaire (congé long, incident de sécurité)
Départ	Désactivation, retrait des droits, puis suppression selon la politique de conservation

L’alimentation des comptes s’appelle le provisionnement. Elle peut être manuelle, synchronisée depuis un annuaire LDAP ou un SIRH, ou réalisée au fil de l’eau lors de la première connexion.

Le départ est l’étape la plus sensible. Un compte oublié reste une porte d’entrée. Et, comme le montre le quiz, désactiver un compte n’interrompt pas toujours les sessions en cours : les jetons déjà émis restent valides jusqu’à leur expiration. C’est une des raisons pour lesquelles on garde des durées de vie de jetons courtes.