Auteur/autrice : Guillaume Dale

Environnement : Debian 12 • PingIDM 8.0.1 • PostgreSQL 17 • Java Temurin 17

Conventions : Toutes les commandes sont exécutées en tant qu’utilisateur standard avec sudo quand l’élévation de privilèges est nécessaire.
Le répertoire d’installation est /opt/openidm/ (le zip extrait un dossier openidm/).

Étape 1 – Mise à jour du système

sudo apt update -y && sudo apt upgrade -y

Étape 2 – Installation de Java (Temurin JDK 17)

PingIDM 8 requiert JDK 17.0.3 ou supérieur. La doc officielle recommande Eclipse Temurin.

sudo apt install -y wget apt-transport-https gnupg

wget -O - https://packages.adoptium.net/artifactory/api/gpg/key/public \
    | sudo tee /usr/share/keyrings/adoptium.asc

echo "deb [signed-by=/usr/share/keyrings/adoptium.asc] \
  https://packages.adoptium.net/artifactory/deb \
  $(awk -F= '/^VERSION_CODENAME/{print$2}' /etc/os-release) main" \
  | sudo tee /etc/apt/sources.list.d/adoptium.list

sudo apt update -y
sudo apt install -y temurin-17-jdk

Configurer JAVA_HOME

echo "export JAVA_HOME=/usr/lib/jvm/temurin-17-jdk-amd64" | sudo tee -a /etc/environment
source /etc/environment
java -version

Étape 3 – Installation de PostgreSQL

PingIDM 8.0.1 supporte PostgreSQL 16 et 17.

sudo apt install -y postgresql postgresql-contrib
sudo systemctl enable --now postgresql
sudo systemctl status postgresql

Étape 4 – Installation des utilitaires

sudo apt install -y wget unzip curl

Étape 5 – Créer un utilisateur dédié et déployer le binaire PingIDM

Le zip contient un dossier openidm/. On l’extrait directement dans /opt/ pour obtenir /opt/openidm/.

sudo useradd -r -m -d /opt/openidm -s /bin/bash openidm
cp IDM-8.0.1.zip /tmp/
cd /opt
sudo unzip /tmp/IDM-8.0.1.zip
sudo chown -R openidm:openidm /opt/openidm
rm /tmp/IDM-8.0.1.zip

Étape 6 – Configurer PostgreSQL pour IDM

6.1 – Modifier pg_hba.conf

sudo nano /etc/postgresql/17/main/pg_hba.conf

Ajouter :

local   all   openidm   trust
local   all   postgres  trust

Note : trust est acceptable en lab. En production, utiliser md5 ou scram-sha-256.

Puis redémarrer PostgreSQL :

sudo systemctl restart postgresql

6.2 – Créer la base de données et le rôle openidm

sudo -u postgres psql -f /opt/openidm/db/postgresql/scripts/createuser.pgsql

6.3 – Créer les tables IDM

psql -U openidm < /opt/openidm/db/postgresql/scripts/openidm.pgsql

6.4 – Créer les tables Flowable (workflow engine)

psql -d openidm -U openidm < /opt/openidm/db/postgresql/scripts/flowable.postgres.all.create.sql

6.5 – Créer les tables d’audit (optionnel)

psql -d openidm -U openidm < /opt/openidm/db/postgresql/scripts/audit.pgsql

6.6 – Optimisation des index (recommandé)

Relire le script avant exécution pour vérifier que les index correspondent à votre déploiement :

sudo -u postgres psql -d openidm -f /opt/openidm/db/postgresql/scripts/default_schema_optimization.pgsql

Étape 7 – Configurer IDM pour PostgreSQL

7.1 – Supprimer la config DS par défaut

cd /opt/openidm/conf/
sudo rm repo.ds.json

7.2 – Copier les fichiers de configuration PostgreSQL

sudo cp /opt/openidm/db/postgresql/conf/datasource.jdbc-default.json \
        /opt/openidm/conf/

sudo cp /opt/openidm/db/postgresql/conf/repo.jdbc.json \
        /opt/openidm/conf/

7.3 – Configurer la connexion JDBC

Éditer datasource.jdbc-default.json si vous avez changé le mot de passe de l’utilisateur openidm :

sudo nano /opt/openidm/conf/datasource.jdbc-default.json

Contenu attendu :

{
  "driverClass" : "org.postgresql.Driver",
  "jdbcUrl" : "jdbc:postgresql://&{openidm.repo.host}:&{openidm.repo.port}/openidm",
  "databaseName" : "openidm",
  "username" : "openidm",
  "password" : "openidm",
  "connectionTimeout" : 30000,
  "connectionPool" : {
    "type" : "hikari",
    "minimumIdle" : 20,
    "maximumPoolSize" : 50
  }
}

7.4 – Configurer boot.properties

sudo nano /opt/openidm/resolver/boot.properties

Ou exporter la variable OPENIDM_OPTS :

export OPENIDM_OPTS="-Xmx2048m -Xms2048m -Dopenidm.repo.host=localhost -Dopenidm.repo.port=5432"

Étape 8 – Configurer les locales (si nécessaire)

sudo dpkg-reconfigure locales
sudo nano /etc/default/locale
sudo reboot

PostgreSQL nécessite des locales UTF-8 correctement configurées.

Étape 9 – Démarrer PingIDM

sudo su - openidm
cd /opt/openidm
./startup.sh

Sortie attendue :

Using OPENIDM_HOME: /opt/openidm
Using PROJECT_HOME: /opt/openidm
Using OPENIDM_OPTS: -Xmx2048m -Xms2048m ...
-> OpenIDM version "8.0.1"
OpenIDM ready

IDM écoute par défaut sur les ports 8080 (HTTP) et 8443 (HTTPS).

Note production : Configurez openidm.host dans boot.properties sur l’URL de votre déploiement, sinon les redirections vers /admin ne fonctionneront pas correctement.

Références

• Documentation officielle PingIDM 8.0.1 — Installation
• PostgreSQL Repository
• Java Requirements
• Before You Install

Pourquoi le PBAC s’impose aujourd’hui

Les organisations modernes doivent sécuriser les accès sans freiner le métier. 

Les modèles classiques, comme le Role-Based Access Control (RBAC), ont montré leurs limites : multiplication des rôles, exceptions à répétition, gouvernance complexe. 

Le Policy-Based Access Control (PBAC) répond à ces enjeux. 

Ce modèle de nouvelle génération prend des décisions d’accès dynamiques, basées sur le contexte plutôt que sur des rôles statiques. 

Résultat : une sécurité plus flexible, précise et traçable, trois piliers essentiels de tout projet IAM moderne.

Du rôle à la politique : une révolution naturelle

Le RBAC a longtemps dominé la gestion des accès.

Solide dans des environnements stables, il devient rigide dès que les utilisateurs, les applications ou les données évoluent rapidement. 

L’attribute-Based Acces Control (ABAC) a introduit plus de contexte grâce ayx attributs (département, localisation, fonction).

Le PBAC va plus loin : il traduit la logique métier en politique combinant attributs, conditions et contexte pour des décisions d’accès en temps réel. 

Exemple : 

• RBAC : « Alice a le rôle RH »

• PBAC :  » Autoriser Alice à consulter les données RH si elle appartient au service RH et si la demande est effectuée pendant des heures de travail. »

Comment fonctionne le PBAC 

Les composants essentiels du PBAC

Le modèle PBAC repose sur quatre points clés, qui structurent la chaîne de décisions d’accès : 

• PAP – Policy Administration Point : point central où les politiques sont crées, gérées et distribuées. 

• PDP – Policy Decision Point : moteur de décision, il évalue les politiques et détermine si l’accès est autorisé. 

• PEP – Policy Enforcement Point : il applique la décision du PDP sur la ressource concernée. 

• PIP – Policy Information Point : il fournit les attributs et les informations contextuelles nécessaires à la décision

Ensemble, ces composants forment un système cohérent où chaque requête d’accès est évaluée, validée et tracée en temps réel. 

PBAC en pratique : l’exemple d’Alice

Prenons un cas concret : 

1. Demande : Alice veut accéder aux données des employés

2. Décision : Le PDP regarde les politiques actives et les attributs d’Alice : 

3. 1. Politique : « Le groupe RH peut accéder aux données des employés en lecture seule » 
   2. Attribut : « Alice est membre du groupe RH » 

4. Résultat : Le PDP autorise l’accès en lecture d’Alice et le PEP applique cette décision

Si Alice quitte le groupe RH, sa prochaine demande sera refusée automatiquement, sans intervention manuelle. 

Le PBAC assure ainsi un contrôle dynamique et contextuel des autorisations. 

Les prérequis d’un projet PBAC réussi

Le PBAC est un modèle puissant, mais il exige une maturité IAM avancée et une gouvernance solide.

Sa mise en oeuvre repose sur plusieurs clés :

• Une architecture IAM intégrée : Interconnexion entre IAG, AM et sources de données. 

• Une modélisation des besoins métier claire : savoir QUI accède à QUOI, et dans QUELLES conditions. 

• Une gouvernance rigoureuse : politique conçue, testée et documentée comme du code.

La réussite passe par une approche progressive : commencer petit, tester, ajuster, puis étendre. 

Quand adopter le PBAC ? 

Le PBAC s’adresse particulièrement aux organisations qui : 

• évoluent sous fortes contraintes réglementaires (finances, santé, secteur public) ; 
• gèrent plusieurs applications, partenaires ou environnements ; 
• disposent déjà d’une base IAM mature (IAG, AM, PAM). 

C’est aussi un levier stratégique pour le Zéro Trust, où chaque accès est continuellement vérifié selon le contexte et le niveau de risque. 

PBAC VS autres modèles 

Modèle	Base	Force	Limitation	Maturité IAM
RBAC	Rôles	Simple à comprendre	Rigide, difficile à évoluer	Intermédiaire
ABAC	Attributs	Contextuelle	Difficile à gouverner	Avancé
PBAC	Politiques	Dynamique, évolutif, auditable	Complexe à implémenter	Expert

De nombreuses entreprises adoptent une approche hybride : RBAC pour les accès standards, PBAC pour les autorisations sensibles et à forte granularité. 

Vers une gouvernance des accès modernes 

Le PBAC marque une évolution majeure dans la gestion des identités et des accès. 

Plutôt que de maintenir des milliers de rôles, il permet de centraliser les politiques, d’en améliorer la traçabilité et d’aligner la sécurité sur les besoins métiers. 

Bien implémenté, le PBAC devient le moteur décisionnel de la gouvernance des accès, garantissant que chaque autorisation est explicable et contextualisée. 

En résumé, le PBAC illustre parfaitement la philosophie Ariovis : « Security meets Business ». 

Le modèle périmétrique traditionnel devient de plus en plus obsolète. Une fois qu’un attaquant rentre dans le SI et a l’accès au réseau interne, il peut se déplacer latéralement (cela signifie qu’il peut explorer et accéder à des systèmes et des services dans le réseau) souvent sans authentification forte ou un contrôle des autorisations à chaque étape.

Ce manque de contrôle permet à l’attaquant de faire une élévation de privilège, d’accéder à des données sensibles, ou de compromettre d’autres systèmes.

C’est là que le Zero Trust entre en jeu. En Zero Trust, on ne fait confiance à rien et à personne par défaut, même dans le périmètre. Les tentatives d’accès sont vérifiées dynamiquement en prenant en compte l’identité, le contexte et la posture de sécurité.

L’IAM (Identity and Access Management) a pour objectif de :

• Vérifier l’identité (humain et non-humain)
• Appliquer les politiques d’accès conditionnels
• Gérer les droits avec des modèles (RBAC, ABAC, CBAC)

Dans cet article, nous allons voir que l’IAM n’est pas juste une brique, mais un pilier d’une stratégie Zero Trust.

 

Zero Trust en bref selon le NIST

C’est quoi le Zero Trust ?

Le NIST (National Institute of Standards and Technology) répond à la question dans une publication nommé Zero Trust Architecture. 

Le NIST définit le Zero Trust comme un paradigme qui n’accorde pas de confiance implicite à un utilisateur, appareil ou un réseau (qu’il soit interne ou externe). L’accès à une ressource doit être authentifié, autorisé et validé en continu.

 

Les 7 piliers du Zero Trust

Pour mettre en place une bonne stratégie Zero Trust, le NIST retient 7 piliers de valeurs :

1. Ressources : Tout les assets (données, appareils, …) sont considérés comme des ressources.
2. Communication : On ne fait plus confiance aux communications, qu’elles soient internes aux équipements de l’entreprise, ou venant de l’extérieur. En conséquence, on doit appliquer par défaut les mêmes mesures de sécurité (elles doivent être authentifiées et autorisées).
3. Accès par session : Les accès sont accordés par session avec un contrôle granulaire.
4. Politiques dynamiques : Les décisions d’accès sont basées sur des politiques dynamiques qui incluent une analyse du contexte et du comportement.
5. Surveillance : L’intégrité et la sécurité des assets de l’entreprise doivent être surveillées en continu.
6. Authentification & Autorisation : L’accès aux ressources est authentifié et autorisé dynamiquement grâce à une surveillance, une réévaluation et une application continues des politiques afin de maintenir un équilibre entre la sécurité et l’efficacité.
7. Amélioration continue : L’organisation doit collecter le plus d’informations possible sur ses assets, son infrastructure et ses réseaux ainsi que ses communications dans le but de renforcer ses politiques de sécurité.

 

Composants logiques d’une ZTA

Il y a plusieurs composants logiques nécessaire à la mise en place d’une ZTA (Zero Trust Architecture). Ces composants sont des services qui peuvent être On-Premises ou même en Cloud.

Voici la description des composants :

• Policy Engine (PE) : Prend les décisions d’accès.
• Policy Administrator (PA) : Applique les décisions via le réseau.
• Policy Enforcement Point (PEP) : Applique les politiques d’accès au niveau de la ressource.
• Data sources : CDM, PKI, SIEM, IAM, etc.

IAM : Les fondations d’une politique ZTA

L’IAM est au cœur du Zero Trust

L’IAM, c’est elle qui va gérer, vérifier et contrôler les identités (humains et non-humains). Il permet un contrôle granulaire et dynamique des accès en s’appuyant sur les attributs, le contexte (localisation, heure) et le contexte comportemental.

En Zero Trust, chaque décision dépend d’une vérification précise de l’identité et d’une évaluation du contexte en temps réel. Ces deux points sont gérés par l’IAM.

Sans l’IAM, une stratégie Zero Trust ne pourrait pas être pertinente.

 

Composants IAM essentiels

Plusieurs composants de l’IAM sont primordiaux pour mettre en place une ZTA. Ariovis propose ici une liste des essentiels :

• Gestion du cycle de vie des identités : Onboarding, Offboarding, Joiner-Mover-Leaver (JML), accès temporaire, tous les processus qui assurent le bon accès au bon moment avec la durée nécessaire.
• Authentification forte : MFA adaptatif, biométrie, passwordless.
• Modèles de droits : Utilisation de modèles de droits comme le RBAC (Role Base Access Control) et/ou ABAC (Attribute Base Access Control) pour le principe du moindre privilège et l’accès contextuel.
• Privileged Access Management (PAM) : Un contrôle et une surveillance strict des comptes administrateurs et sensibles.
• Non-Person Identity (NPE) : Sécuriser la gestion des comptes de service, des clefs API, des secrets et des certificats utilisés par les services, bots et applications.

 

De l’IAM traditionnel à l’IAM Zero Trust

IAM statique vs IAM dynamique

Traditionnellement, l’IAM s’appuie sur une authentification unique lors de la connexion et sur un modèle RBAC statique. L’IAM Zero Trust impose une validation continuelle de l’identité et du contexte lors d’une session. L’accès est réévalué dynamiquement basé sur le contexte.

 

Intégration avec d’autres composants du Zero Trust

L’IAM ne fonctionne pas dans son coin dans une ZTA. Pour que l’IAM soit le plus efficace possible, il doit être intégré dans des composant du Zero Trust :

• UEBA (User and Entity Behavior Analytics) : En analysant le comportement et en détectant les anomalies, l’UEBA permet à l’IAM de déclencher une authentification additionnelle ou de restreindre l’accès dynamiquement.
• Policy Engine (PE) et Policy Administrator (PA) : L’IAM utilise directement ces composants pour appliquer des décisions en temps réel sur un contrôle d’accès. PE et PA vont utiliser les informations de l’IAM pour prendre des décisions granulaires.
• Protocole standard : Les protocoles SAML, OIDC (OpenID Connect) et SCIM sont primordiaux pour fluidifier la fédération d’identité, l’authentification et pour gérer le cycle de vie des identités. Ici, vous pouvez trouver un guide sur comment connecter une application avec OIDC.

 

Migration vers une ZTA

Pour migrer vers une ZTA, il y a deux points clefs selon le NIST :

• Commencer avec une approche hybride : La plupart des organisations utilisent un modèle hybride, qui combine le modèle périmétrique avec une approche Zero Trust.
• Progressive et basée sur des Use Case : La migration devrait être incrémentale, focalisée sur des use cases spécifiques plutôt que sur une transformation totale tout en une fois.

Voici les étapes de migration clef :

1. Identifier les acteurs : Pour commencer, il faut lister les utilisateurs, services et les identités non-humaines qui interagissent avec les ressources. Ne pas oublier les identités qui proviennent du shadow IT, nous appelons cela l’ « Hidden IAM ».
2. Inventaire des assets : Ensuite, il faut dresser un catalogue des hardwares, softwares, données et des services cloud que gère ou possède l’organisation.
3. Identifier les processus clefs : Après, il faut identifier les workflows critiques, et après faire une analyse de risque pour définir les exigences d’accès.
4. Définition des politiques d’accès : Ensuite, il faut développer les politiques dynamiques basées sur les identités, statuts des assets et du contexte (ex : localisation, heure, etc).
5. Sélection des technologies : Avant le déploiement, il faut rechercher et choisir les solutions pour les composants Zero Trust : IAM, PDP, PEP, etc.
6. Déploiement initial et surveillance : On peut maintenant commencer le déploiement de la ZTA. On commence par les use cases avec un risque faible. On surveille la nouvelle architecture et, si besoin, on fait des ajustements sur les configurations.
7. Étendre le ZTA : Pour finir, on continue le déploiement sur des systèmes de plus en plus critiques.

 

Conclusion

L’IAM, c’est bien plus qu’un composant de cybersécurité, c’est un pilier d’une bonne stratégie Zero Trust. Dans un monde où l’identité est une cible majeure des attaquants, l’IAM est la tour de contrôle pour vérifier, autoriser et surveiller en continu chaque demande d’accès.

Chez Ariovis, nous appliquons ces principes chez nos clients.  Dans toutes nos intégrations, on utilise une approche Zero Trust. Cela implique que chaque solution que nous implémentons n’a pas de confiance implicite, impose de l’authentification à chaque étape et applique des règles dynamiques suivant le contexte. Pour nous, le Zero Trust n’est pas qu’un « buzzword », mais un modèle concret ancré au cœur de nos projets IAM.