IAM & Authentification

Objectif & portée¶

Définir identité, authentification, autorisation, audit et gouvernance
Couvrir comptes humains et techniques (services, webhooks, jobs)

Principes¶

Horodatage¶

Les timestamps échangés par l'API sont en UTC (suffixe Z). L'heure locale (UTC+1) est réservée à l'UI.
Least privilege, Zero Trust, séparation des rôles
RBAC enrichi d'ABAC (tenant, channel, environment, data_class)
Traçabilité par correlation_id, X-Request-Id, trace_id (immutables)

Modèle d'accès (RBAC/ABAC)¶

Rôles & permissions (extraits)¶

Rôle	Portée	Permissions clés
Viewer	Tenant	lire métriques/logs
Support Agent	Tenant	lire conversations, créer tickets
Tenant Admin	Tenant	gérer policies/canaux/utilisateurs
Security Admin	Global	audit, secrets, politiques sécurité
Platform Admin	Global	déploiements, config système

Attributs ABAC¶

Attribut	Exemple	Usage
tenant	acme	isolation multi-tenant
channel	webchat/facebook/whatsapp	contraindre par canal
environment	prod/stage	limiter opérations sensibles
data_class	public/internal/restricted	masquage/redaction

Modèle RBAC/ABAC¶

Le diagramme suivant illustre le modèle d'autorisation hybride RBAC/ABAC :

graph TB
    subgraph "Utilisateur/Service"
        U[Utilisateur]
        S[Service M2M]
    end

    subgraph "Authentification"
        SSO[SSO OIDC/SAML]
        JWT[JWT Token]
        MTLS[mTLS Cert]
    end

    subgraph "Autorisation Gateway"
        GW[API Gateway]
        RBAC[Évaluation RBAC]
        ABAC[Évaluation ABAC]
    end

    subgraph "Rôles (RBAC)"
        V[Viewer]
        SA[Support Agent]
        TA[Tenant Admin]
        SEC[Security Admin]
        PA[Platform Admin]
    end

    subgraph "Attributs (ABAC)"
        T[tenant: acme]
        C[channel: webchat]
        E[environment: prod]
        DC[data_class: restricted]
    end

    subgraph "Permissions"
        R[messages:read]
        W[policies:write]
        A[audit:access]
        D[deploy:manage]
    end

    subgraph "Ressources"
        MSG[Messages]
        POL[Policies]
        LOG[Logs/Audit]
        SYS[Système]
    end

    %% Flux authentification
    U --> SSO
    S --> MTLS
    SSO --> JWT
    MTLS --> JWT

    %% Flux autorisation
    JWT --> GW
    GW --> RBAC
    GW --> ABAC

    %% Évaluation RBAC
    RBAC --> V
    RBAC --> SA
    RBAC --> TA
    RBAC --> SEC
    RBAC --> PA

    %% Évaluation ABAC
    ABAC --> T
    ABAC --> C
    ABAC --> E
    ABAC --> DC

    %% Attribution permissions
    V --> R
    SA --> R
    TA --> W
    SEC --> A
    PA --> D

    %% Contraintes ABAC
    T -.-> R
    C -.-> R
    E -.-> W
    DC -.-> A

    %% Accès ressources
    R --> MSG
    W --> POL
    A --> LOG
    D --> SYS

    style U fill:#e3f2fd
    style S fill:#e3f2fd
    style GW fill:#fff3e0
    style RBAC fill:#e8f5e8
    style ABAC fill:#fce4ec
    style MSG fill:#f3e5f5
    style POL fill:#f3e5f5
    style LOG fill:#f3e5f5
    style SYS fill:#f3e5f5

Identité & Authentification¶

M2M (services)¶

Préférer mTLS (mutual TLS) ou private_key_jwt (OAuth2 client credentials signés) aux API keys.
Scoper chaque client à un tenant et des scopes minimaux ; TTL des tokens M2M ≤ 24h ; rotation des credentials ≤ 90j.
API keys tolérées uniquement par exception (ex: webhooks tiers), avec least privilege, rotation ≤ 90j, et allowlist IP optionnelle.
Interdire le partage de secrets entre services ; un secret unique par service/environnement.
SSO OIDC/SAML; SCIM; MFA pour rôles privilégiés
Comptes break-glass en coffre, durée limitée
Rotation/révocation des tokens au offboarding/suspicion

JWT claims (exemple)¶

{
  "sub": "user_123",
  "tenant": "acme",
  "roles": ["tenant_admin"],
  "scopes": ["policies:write"],
  "exp": 1734300000,
  "jti": "req-abc"
}

Autorisation API¶

Headers requis: Authorization, X-SalamBot-Tenant, X-Request-Id
Évaluation scopes + RBAC/ABAC en gateway/orchestrateur
Idempotency-Key exigé pour POST critiques

Scopes (exemples)¶

Scope	Description	Endpoints
messages:analyze	analyser messages	POST /v1/messages/analyze
search:query	requêtes RAG	POST /v1/search/query
policies:read	lire politiques	GET /v1/admin/policies
policies:write	modifier politiques	PUT /v1/admin/policies

Appel signé (cURL)¶

curl -s "$BASE_URL/admin/policies" \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-SalamBot-Tenant: acme" \
  -H "X-Request-Id: $(uuidgen | tr 'A-Z' 'a-z')"

Provisioning & cycle de vie¶

SCIM: création/suspension/suppression
JIT via claims OIDC mappés aux rôles
Offboarding: retrait rôles, révocation sessions/tokens

Mapping rôles (yaml)¶

mappings:
  - claim: groups
    when: acme-admins
    assign_roles: [tenant_admin]

Sécrets & sessions¶

Coffre KMS/HashiCorp; jamais en clair dans git/logs
Rotation périodique JWT/webhooks/API keys (≤90j)
Expirations/refresh et liste de révocation centralisées

API keys — stockage & format¶

Générer côté serveur (préfixes sk_live_ / sk_test_).
Stockage hashé (HMAC-SHA256 avec clé KMS) + salt ; ne jamais ré-afficher le secret après création.
Exposer uniquement l'ID et les scopes côté UI/Logs ; pas de secret en clair.
Révocation immédiate avec revoked_at, recherche par fingerprint.

Sessions & refresh tokens¶

Rotation à chaque usage (refresh token rotation) avec détection de réutilisation ; révoquer la famille en cas d'abus.
Inactivité maximale 7 jours (idle timeout) en plus du TTL global (accès ≤60 min, refresh ≤30 j).
Lier la session à des signaux doux (hash UA, /24 IP) avec tolérance ; alerter en cas de changement brusque.

PAM (accès privilégiés)¶

Élévation JIT approuvée, durée limitée, justification
Journaliser before/after, cible, corrélation, résultat
Accès d'urgence (break-glass) avec postmortem auto

Audit & journalisation¶

Journaliser qui/quoi/quand/où/pourquoi
Conserver correlation_id, X-Request-Id, trace_id
Rétention conforme CNDP/RGPD; pas de PII dans labels

Entrée d'audit (JSON)¶

{
  "ts": "2025-08-14T10:30:00Z",
  "actor": "user_123",
  "tenant": "acme",
  "action": "policies.update",
  "target": "/v1/admin/policies",
  "result": "success",
  "correlation_id": "corr_abc"
}

Politiques ABAC (OPA)¶

Rego — write policies¶

package salambot.auth

# Chemin sous forme de chaîne (ex: "/v1/admin/policies")
allow {
  input.m == "PUT"
  input.p == "/v1/admin/policies"
  "policies:write" in input.jwt.scopes
  input.jwt.tenant == input.h["X-SalamBot-Tenant"]
}

# Variante si le chemin est segmenté (ex: ["v1","admin","policies"])
allow {
  input.m == "PUT"
  input.path == ["v1", "admin", "policies"]
  "policies:write" in input.jwt.scopes
  input.jwt.tenant == input.h["X-SalamBot-Tenant"]
}

Webhooks & signatures¶

Source unique : voir API/reference.md (Webhooks & HMAC).

Conformité & gouvernance¶

CNDP loi 09-08 & RGPD: base légale, minimisation, droits (accès/effacement/portabilité).
DPO désigné ; notification d'incident PII ≤72 h (voir Runbooks PII).
DPIA requise pour nouveaux traitements à risque (canaux, enrichissements, transferts).
Interdit: PII dans logs/labels/metrics ; activer redaction/pseudonymisation côté gateway.
Rétention recommandée: journaux d'audit 12 mois, logs applicatifs 90 j, métriques agrégées 12 mois.
Localisation des données: Maroc/UE ; contrats de sous-traitance et SCC si export.
Revues trimestrielles des rôles/scopes et attestations d'accès.

Checklists IAM¶

Onboarding¶

SSO (OIDC/SAML) actif, SCIM provisionné, MFA forcée pour rôles sensibles.
Rôle minimal attribué (RBAC) + attributs ABAC vérifiés (tenant/channel/env).
Clés/API de service en coffre (KMS/HC Vault), TTL et rotation définis.
Test d'accès réussi: GET /v1/admin/policies (trace et audit présents).

Offboarding¶

Désactiver via SCIM ; révoquer sessions/tokens/clefs.
Retrait des groupes SSO et rôles ; transfert d'ownership des ressources.
Vérification d'absence d'accès résiduel (logs d'auth 7 j).

Revue mensuelle¶

Comparer rôles vs. organigramme RH ; supprimer comptes inactifs >90 j.
Rotation des secrets échus ; analyse des tentatives d'accès échouées.
Export du journal d'audit signé et archivage conforme.

Normes tokens & crypto¶

JWT: RS256/ES256, TTL accès ≤ 60 min, refresh ≤ 30 j, aud=service, iss=IdP.
Vérifications: exp, nbf/iat (skew ±60s), présence sub, tenant, roles/scopes, jti unique (anti-rejeu ≥24 h).
JWKS: pinning par kid, rotation ≤90 j, cache ≤15 min, fallback safe si clé manquante (refuser la requête).
Webhooks: HMAC-SHA256 secret ≥32 octets (hex/base64), comparer via hmac.compare_digest, fenêtre temporelle ±5 min par tenant.
Sécurité TLS: TLS 1.2+ only, désactiver suites faibles, HSTS côté gateway.

Interdictions crypto¶

Algorithmes refusés : alg="none", HS256/HS512 pour SSO (exiger RS256/ES256) ; MD5/SHA1 proscrits.
JWT : vérifier alg/kid contre la denylist/allowlist ; refuser si clé JWKS introuvable ou signature invalide (pas de fail open).
TLS : préférer TLS 1.3, exiger PFS ; désactiver suites RC4/3DES.

Références croisées¶

Runbooks : procédures d'incident sécurité
SLO & SLA : métriques d'authentification
API Reference : endpoints d'administration