Fondamentaux de la gestion des identités¶

Authentification vs Autorisation¶

Ces deux concepts sont complementaires mais distincts. Un utilisateur peut etre authentifie (identité verifiee) sans etre autorise a accéder à une ressource particulière.

Protocoles d'authentification¶

OpenID Connect (OIDC)¶

Standard moderne base sur OAuth 2.0. Utilise des tokens JWT pour transmettre l'identité de manière securisee.

graph LR
    User["Utilisateur"] --> App["Application"]
    App --> IdP["Redirection vers IdP"]
    IdP --> Login["Login + MFA"]
    Login --> Code["Code d'autorisation"]
    Code --> Token["Echange contre Token JWT"]
    Token --> App

Quand l'utiliser : applications web, APIs, services cloud. C'est le protocole par defaut pour les nouvelles integrations.

Composants cles :

SAML 2.0¶

Standard plus ancien, base sur XML. Encore largement utilise par les applications d'entreprise et les SaaS.

graph LR
    User["Utilisateur"] --> SP["SP (Service Provider)"]
    SP --> IdP["Redirection vers IdP"]
    IdP --> Login --> Assertion["Assertion SAML signee"]
    Assertion --> SP2["SP"] --> Session

Quand l'utiliser : integration avec des SaaS qui ne supportent pas OIDC, applications d'entreprise legacy, federations inter-organisations.

LDAP / LDAPS¶

Protocole d'annuaire pour stocker et interroger les identités. Ce n'est pas un protocole d'authentification a proprement parler, mais un backend d'identités.

graph LR
    App["Application"] -->|LDAP bind<br/>uid=fabien,ou=users,<br/>dc=example,dc=com| LDAP["Verification<br/>mot de passe"]

Quand l'utiliser : backend d'identités pour Keycloak, integration avec des services legacy (PAM, sudo, SSH), annuaire de groupes et d'attributs.

Kerberos¶

Protocole d'authentification par tickets, base sur la cryptographie symetrique. Natif dans les environnements Active Directory et FreeIPA.

Quand l'utiliser : environnements Windows/AD, authentification transparente (SSO Kerberos), integration Linux via SSSD.

SCIM (System for Cross-domain Identity Management)¶

Standard de provisioning automatique des identités entre un IdP et les applications.

graph LR
    RH["RH ajoute<br/>un collaborateur"] --> IdP["IdP (Keycloak)"]
    IdP -->|SCIM push| Gitea
    IdP -->|SCIM push| Grafana
    IdP -->|SCIM push| Nextcloud

Quand l'utiliser : automatiser le cycle de vie des comptes (creation, modification, suppression) dans les applications connectees.

Modèles d'autorisation¶

RBAC (Rôle-Based Access Control)¶

Le modèle le plus repandu. Les permissions sont attribuees a des rôles, les rôles sont attribues aux utilisateurs.

graph LR
    Utilisateur --> Role --> Permissions

Exemple :

• Utilisateur fabien → Rôle platform-engineer → Permissions [read:metrics, write:infra, admin:cicd]
• Utilisateur alice → Rôle developer → Permissions [read:metrics, read:infra, write:code]

ABAC (Attribute-Based Access Control)¶

Les decisions d'accès sont basées sur des attributs de l'utilisateur, de la ressource et du contexte.

Si (utilisateur.departement == "engineering"
    ET ressource.classification <= "confidentiel"
    ET heure.actuelle ENTRE 8h ET 20h)
→ AUTORISER

Quand l'utiliser : quand le RBAC ne suffit plus (regles contextuelles, horaires, localisation).

ReBAC (Relationship-Based Access Control)¶

Les decisions d'accès sont basées sur les relations entre entites (Google Zanzibar, OpenFGA).

utilisateur:fabien EST membre DE groupe:platform-team
groupe:platform-team EST proprietaire DE repo:infra
→ fabien PEUT ecrire DANS repo:infra

Quand l'utiliser : systèmes avec des relations complexes entre objets (partage de documents, organisations multi-tenant).

Authentification multi-facteurs (MFA)¶

Méthodes MFA recommandees¶

Cycle de vie des identités (JML)¶

Le modèle Joiner/Mover/Leaver structure les processus RH-IT :

graph LR
    A[RH: nouvel employe] --> B[IdP: creation compte]
    B --> C[SCIM: provisioning apps]
    C --> D[Manager: validation acces]
    D --> E[Collaborateur actif]
    E --> F[RH: changement poste]
    F --> G[IdP: maj roles]
    G --> H[SCIM: maj apps]
    E --> I[RH: depart]
    I --> J[IdP: desactivation]
    J --> K[SCIM: deprovisioning]
    K --> L[Archivage 90j puis suppression]

Fédération d'identités¶

La fédération permet à des organisations distinctes de partager l'authentification sans partager les credentials.

Cas d'usage¶

• SSO interne : un seul login pour tous les services de la DSI
• Fédération inter-organisations : partenaires, sous-traitants qui utilisent leur propre IdP
• Social login : connexion via Google, GitHub, Microsoft (pour les services exposes)
• Identity brokering : Keycloak comme broker qui aggrege plusieurs IdP upstream