Désactivation d'un compte et révocation des accès

Quand un utilisateur est désactivé ou supprimé (départ d’un salarié, fin de contrat, compte compromis), ses accès en cours doivent cesser sans attendre l’expiration de ses sessions et de ses jetons. À partir de la version 3.38.0, TOSIAM le fait de lui-même, quel que soit l’endroit où la modification a été faite.

1. Ce qui déclenche la révocation#

La révocation a lieu dans deux cas :

• l’utilisateur n’est plus actif (inetUserStatus: Inactive, ou nsAccountLock selon l’annuaire) ;
• l’utilisateur est supprimé.

TOSIAM l’apprend par deux voies, qui couvrent tous les canaux de modification :

La seconde voie sert aux annuaires qui n’envoient pas de notification : la révocation a lieu même sans recherche persistante, tant que la modification passe par TOSIAM.

2. Ce qui est révoqué#

Sessions#

TOSIAM cherche les sessions de l’utilisateur dans le Core Token Store et les ferme comme une déconnexion. Le traitement habituel de la déconnexion a donc lieu, y compris la déconnexion par canal dérobé des applications OpenID Connect.

Jetons OAuth2#

Les jetons d’accès et de rafraîchissement de l’utilisateur sont supprimés, pour tous ses clients, comme lorsque l’utilisateur révoque lui-même une application. Une introspection répond "active": false, et un rafraîchissement est refusé.

Les consentements sont gardés. Une désactivation est réversible : un utilisateur réactivé se reconnecte avec ses moyens d’authentification d’origine et retrouve ses applications, sans nouveau consentement.

3. Délai#

La révocation est faite sur un fil de fond, pour ne ralentir ni l’écriture ni la notification. Elle a lieu quelques secondes après la modification. Les tests de non-régression la vérifient en 30 secondes au plus, sur TosDJ et sur OpenLDAP.

Chaque serveur du site reçoit la notification et révoque de son côté. Une session ou un jeton déjà révoqué par un autre serveur est simplement ignoré.

4. Cas particuliers#

Sessions et jetons sans état#

• Jeton OAuth2 sans état (JWT) : TOSIAM le révoque (liste de révocation) et le refuse ensuite à l’introspection et à userinfo. Un serveur de ressources qui valide seulement la signature ne voit pas la révocation, et accepte le jeton jusqu’à son expiration (voir Jetons OAuth2). Pour qu’un départ prenne effet aussitôt, faites valider les jetons par introspection, ou gardez-leur une durée de vie courte.
• Session sans état : elle n’est pas enregistrée dans le Core Token Store. TOSIAM ne peut pas la retrouver, et elle reste acceptée jusqu’à son expiration. Le délai est borné par sa durée de vie.

Annuaire sans notification#

Si le data store n’a pas de base de recherche persistante (sun-idrepo-ldapv3-config-psearchbase), une désactivation écrite directement dans l’annuaire n’est pas notifiée : elle bloque les nouvelles authentifications, mais ne révoque rien. Seules les écritures faites par TOSIAM révoquent alors. Voir Cache des identités et annuaires sans notification et, pour OpenLDAP, Utiliser OpenLDAP comme annuaire des identités.

Codes d’autorisation#

Un code d’autorisation émis juste avant la désactivation n’est pas révoqué, et peut encore être échangé contre des jetons pendant sa durée de vie, courte. Le jeton de rafraîchissement ainsi obtenu sera refusé, puisque le rafraîchissement vérifie que l’utilisateur est toujours actif. Le jeton d’accès, lui, reste valide jusqu’à son expiration.

5. Réglage et suivi#

La révocation est active par défaut. Elle se désactive par une propriété serveur :

org.tst.tosiam.idm.revokeOnDisable=false

Elle n’a lieu que dans le serveur TOSIAM : ssoadm et les outils, qui chargent les data stores dans leur propre processus, ne révoquent rien eux-mêmes. Une modification faite par ssoadm à travers le serveur est traitée normalement.

Chaque révocation est tracée au niveau INFO :

Un échec est tracé au niveau WARN (The credentials of <identifiant> are not revoked), sans bloquer la modification de l’utilisateur.