TOSIAM avec un outil de gestion des identités

TOSIAM authentifie les utilisateurs et contrôle leurs accès. Il ne décide pas qui doit exister, dans quels groupes, ni jusqu’à quand. C’est le rôle d’un outil de gestion des identités : il tire les identités d’une source qui fait autorité (le système RH), les écrit dans l’annuaire utilisé par TOSIAM et les tient à jour tout au long de leur cycle de vie.

Dans la suite TOSIAM, cet outil est TOSIDM, un fork d’OpenIDM porté sur les bibliothèques communes de TOSIAM (dépôt theopensourceitrust/tosiam-idm). Cette page décrit l’association des trois briques et la configuration à faire de chaque côté.

1. La chaîne complète#

Source RH (hr.csv)
   │  réconciliation systemHrAccount_managedUser
   ▼
TOSIDM : managed/user
   │  synchronisation implicite (connecteur LDAP)
   ▼
TosDJ : uid=…,ou=people  +  membre de cn=<service>,ou=groups
   │  recherche persistante du data store
   ▼
TOSIAM : connexion, groupes, révocation des sessions et des jetons au départ

TOSIDM écrit directement dans l’annuaire, en LDAP. Aucun service SCIM n’est nécessaire côté TOSIAM : le data store voit les entrées comme si un administrateur les avait créées.

2. Côté TOSIAM#

Data store avec recherche persistante#

Le data store du royaume pointe sur l’annuaire où écrit TOSIDM, et il doit avoir une base de recherche persistante (sun-idrepo-ldapv3-config-psearchbase, le suffixe par exemple). Sans elle, TOSIAM relit toujours le statut des comptes, mais garde en cache le reste, dont les membres des groupes, jusqu’à l’expiration du cache (voir Cache des identités et annuaires sans notification).

Révocation au départ#

À partir de 3.38.0, TOSIAM révoque les sessions et les jetons OAuth2 (jetons d’accès et de rafraîchissement) d’un utilisateur dès qu’il est désactivé ou supprimé, quel que soit le canal :

• une écriture de TOSIDM, vue par la recherche persistante ;
• une écriture directe dans l’annuaire ;
• l’API ou la console de TOSIAM.

Les consentements OAuth2 sont gardés : un utilisateur réactivé n’a pas à les redonner. La révocation est active par défaut. Elle se désactive par la propriété serveur org.tst.tosiam.idm.revokeOnDisable=false. Délais, cas sans état et verrouillage de compte : voir Désactivation d’un compte et révocation des accès.

Groupes des services#

Les groupes cn=<service>,ou=groups,<suffixe> sont créés hors de TOSIDM, dans TOSIAM par exemple. TOSIDM n’en gère que l’appartenance, et il fait autorité sur elle : un membre ajouté par un autre moyen est retiré à la modification suivante de l’identité.

3. Côté TOSIDM#

La distribution de TOSIDM contient l’exemple samples/tosiam-tosdj, prêt à l’emploi :

Démarrage#

L’annuaire se décrit par des propriétés système, passées dans OPENIDM_OPTS :

export OPENIDM_OPTS="-Dtosdj.host=user1.example.com -Dtosdj.port=1389 \
  -Dtosdj.principal=uid=tosiam,ou=system,dc=example,dc=com -Dtosdj.suffix=dc=example,dc=com \
  -Dtosiam.url=https://sso.example.com/tosiam/ \
  -Dtosiam.admin.group=cn=tosidm-admins,ou=groups,dc=example,dc=com"
./startup.sh -p samples/tosiam-tosdj

Le mot de passe du compte de service ne passe pas par une propriété : TOSIDM chiffre le champ credentials au chargement du fichier, avant de substituer les propriétés. Il se fixe une fois TOSIDM démarré, par l’API de configuration :

curl -s -X PATCH -H "Content-Type: application/json" \
  -H "X-OpenIDM-Username: openidm-admin" -H "X-OpenIDM-Password: openidm-admin" \
  "http://localhost:8080/openidm/config/provisioner.openicf/tosdj" \
  -d '[{"operation":"replace","field":"/configurationProperties/credentials","value":"<mot de passe>"}]'

La source RH#

Le fichier data/hr.csv simule l’export du système RH :

"uid","firstName","lastName","email","department","status"
"emma","Emma","Durand","emma@example.com","sales","active"

La réconciliation se lance à la demande, ou par un ordonnancement (schedule-*.json) :

curl -s -X POST -H "X-OpenIDM-Username: openidm-admin" -H "X-OpenIDM-Password: openidm-admin" \
  "http://localhost:8080/openidm/recon?_action=recon&mapping=systemHrAccount_managedUser&waitForCompletion=true"

Deux choix de l’exemple sont à connaître :

• Une ligne retirée du fichier ne change rien. Un départ se signale par le statut : un export partiel ou tronqué ne désactive personne.
• La RH ne fournit pas de mot de passe. Le mot de passe initial est fixé par un administrateur de TOSIDM (PATCH /openidm/managed/user/<id> sur /password), ou par le libre-service de TOSIAM.

Pour une vraie source RH, on remplace le connecteur CSV par celui du système RH (base de données, API REST, LDAP…), en gardant la correspondance.

Comptes orphelins#

La réconciliation de la correspondance managedUser_systemTosdjAccount signale les comptes de TosDJ qui n’ont pas d’identité dans TOSIDM, sans les modifier. Ils apparaissent dans l’audit de la réconciliation avec la situation UNASSIGNED :

curl -s -X POST -H "X-OpenIDM-Username: openidm-admin" -H "X-OpenIDM-Password: openidm-admin" \
  "http://localhost:8080/openidm/recon?_action=recon&mapping=managedUser_systemTosdjAccount&waitForCompletion=true"
curl -s -H "X-OpenIDM-Username: openidm-admin" -H "X-OpenIDM-Password: openidm-admin" \
  "http://localhost:8080/openidm/audit/recon?_queryFilter=situation+eq+%22UNASSIGNED%22"

Pour un annuaire déjà peuplé, la correspondance inverse systemTosdjAccount_managedUser reprend une fois les comptes existants dans TOSIDM.

4. Console de TOSIDM par une session TOSIAM#

Les administrateurs ouvrent la console de TOSIDM avec leur session TOSIAM, sans mot de passe propre à TOSIDM :

1. Sans session, la console renvoie vers la page de connexion de TOSIAM.
2. TOSIAM renvoie à la console par le goto, avec sa session.
3. TOSIDM valide la session auprès de TOSIAM (POST json/sessions/<jeton>?_action=validate), puis retrouve le compte dans TosDJ. Les membres du groupe tosiam.admin.group sont administrateurs de TOSIDM.
4. Chaque requête revalide la session TOSIAM : une déconnexion de TOSIAM ferme aussitôt l’accès à la console.

Les pages de TOSIAM se déclarent dans la configuration de l’interface de TOSIDM (conf/ui-configuration.json). {goto} y est remplacé par l’adresse de la console :

"loginUrl" : "https://sso.example.com/tosiam/auth/?realm=/&goto={goto}#login/",
"logoutUrl" : "https://sso.example.com/tosiam/auth/?realm=/&goto={goto}#logout/"

Côté TOSIAM, deux conditions :

• Le goto doit être autorisé par le service de validation du royaume : validGotoDestinations dans l’API REST, openam-auth-valid-goto-resources pour ssoadm, par exemple https://idm.example.com/admin/*.
• Le cookie de session doit parvenir à la console : elle est servie sur le domaine du cookie, et en HTTPS, puisque le cookie est Secure par défaut.

5. Limites actuelles#

• Pas de signaux de sécurité partagés (SSF/CAEP) : TOSIAM révoque ses propres sessions et jetons au départ, mais ne prévient pas encore les applications qui gardent leur propre session.
• Une console par brique : la console de TOSIDM reste distincte de celle de TOSIAM.
• Rechargement des data stores : juste après la modification des data stores d’un royaume, une requête peut encore utiliser l’ancien jeu de data stores (theopensourceitrust/tosiam#1882). Attendre quelques secondes après une modification.
• Synchronisation silencieuse : une création d’identité dans TOSIDM peut répondre 201 alors que l’écriture dans TosDJ a échoué. Une réconciliation managedUser_systemTosdjAccount rattrape l’écart.

6. Essayer le démonstrateur#

La suite tests/tosidm du dépôt tosiam-indus monte TOSIAM, TosDJ et TOSIDM en conteneurs, et joue de bout en bout l’arrivée, la mobilité, le départ et la réconciliation (Tos1701.py), ainsi que la révocation au départ et la connexion à la console par TOSIAM.