Les limites de la recherche SCIM
La recherche pour les utilisateurs d’une grande organisation Okta n’est pas aussi simple qu’il n’y paraît. Si je souhaite trouver tous les prestataires commerciaux à Los Angeles, je dois utiliser la bonne syntaxe SCIM, sinon je n’obtiendrai pas les résultats attendus. Par exemple, pour trouver des utilisateurs selon des attributs de profil, il vous faudrait quelque chose de similaire à ceci :
profile.department eq "Ventes" et profile.city eq "Los Angeles" et profile.userType eq "Prestataire"
Cette syntaxe est difficile pour de nombreux utilisateurs, car :
- Vous devez connaître la syntaxe spécifique.
- La recherche est basée sur des mots-clés, donc une requête comme « mes subordonnés directs » ne trouvera pas la liste des utilisateurs qui rendent compte à l’administrateur actuel. La console d’administration Okta prend en charge le filtrage par ID de responsable, mais la recherche habituelle ne comprend pas que « mes subordonnés directs » doit se traduire par profile.managerId égal à l’ID de l’administrateur.
- Une petite faute de frappe pourrait signifier zéro résultat ou des résultats inattendus.
Lors d’un récent hackathon interne, nous avons tenté de répondre à une question simple : que se passerait-il si les administrateurs Okta pouvaient simplement saisir ce qu’ils souhaitent en français courant et laisser le système se charger des détails SCIM ? Donc :
Au lieu de | Nous pouvons utiliser |
|---|---|
search=profile.department eq "Ventes" et profile.title eq "Responsable" | Trouve-moi les directeurs et responsables des ventes |
profile.managerId eq "00u1ab2c3d4e" | Montre-moi tous mes subordonnés directs |
Pour répondre à cette question, nous avons créé un prototype : un moteur de recherche sémantique optimisé par l’IA qui interprète le langage naturel, l’associe aux ressources Okta et renvoie les utilisateurs et applications pertinents sans obliger l’administrateur à utiliser une syntaxe SCIM. Dans le reste de cet article, je vous expliquerai comment nous avons assemblé le prototype et vous présenterai notre vision d’une future implémentation prête pour la production.
Workflow global
Lorsqu’un administrateur Okta saisit une requête en langage naturel dans la barre de recherche globale, le back-end Java d’Okta intercepte les appels API (/api/internal/admin/search et /api/v1/internal/applications). Au lieu d’exécuter immédiatement une requête SCIM standard, il effectue un appel API au service d’IA Python avec la requête brute de l’utilisateur.
Le service Python exécute son pipeline de recherche en plusieurs étapes et renvoie une liste classée des ID des utilisateurs et applications pertinents. Le back-end Java prend ensuite ces ID, récupère les objets de ressource complets à partir de la couche de données Okta existante et construit la réponse JSON finale que l’interface utilisateur doit afficher.
Architecture du service d’IA Python
Couche de données : pour le prototype, le service utilise un processus d’indexation hors ligne. Il récupère les utilisateurs et les applications d’une organisation Okta de démo, convertit ces ressources en instantanés JSON locaux, puis crée une représentation textuelle pour l’intégration en aval.
Couche d’IA :
- Service d’intégration : nous utilisons les modèles d’intégration AWS Bedrock (p. ex., Cohere Embed ou Amazon Titan) pour associer chaque document texte à un vecteur. Ces vecteurs sont stockés dans un index FAISS (bibliothèque Facebook AI Similarity Search).
- Traitement en langage naturel (NLP) : nous utilisons des LLM tels qu’Anthropic Claude 4.5 pour interpréter les requêtes et générer des filtres SCIM.
- Compréhension des requêtes : un petit service heuristique extrait les attributs structurés (tels que le département, la ville et l’ID du responsable) de la requête en langage naturel afin d’affiner les résultats de recherche.
Pipeline de recherche avancée :
- Traitement des requêtes : la requête entrante est analysée, enrichie avec des synonymes et convertie en un vecteur.
- Récupération des candidats : nous recherchons les vecteurs les plus proches dans l’index FAISS et attribuons à chaque correspondance un score hybride.
- Affinement des résultats : enfin, nous envoyons les candidats les plus prometteurs à un modèle Cohere Rerank pour les réorganiser avant de renvoyer la liste finale des ID de ressource.
En utilisant l’index vectoriel FAISS dans ce pipeline, nous réduisons l’espace de recherche, qui passe de milliers d’utilisateurs et d’applications à un petit ensemble de candidats. Cela réduit la taille du contexte transmis au modèle Rerank final, ce qui diminue les coûts opérationnels et la latence.
Création sécurisée de l’ensemble de données
Nous avons utilisé une organisation Okta de démo pour éviter de manipuler des données à caractère personnel. Nous avons généré des profils aléatoires d’utilisateurs et d’applications afin de remplir cette organisation avec des données réalistes. Toutes les données ont été créées à l’aide de scripts Python personnalisés et exportées vers des fichiers JSON locaux. Cela nous a permis d’exécuter le système hors ligne en fonction des instantanés.
Conversion d’objets Okta en texte consultable
Des profils bruts d’utilisateurs et d’applications ne suffisent pas à garantir une recherche sémantique efficace. Nous devons également capturer l’intégralité de leur contexte et de leur intention. Notre moteur d’indexation hors ligne gère cette préparation des données avant la création de tout vecteur. Pour les objets Okta, les champs de texte clés sont d’abord combinés en un seul document texte afin de garantir que le modèle d’intégration reçoive une description unique à interpréter.
Ces documents sont ensuite enrichis en tenant compte des limites connues des données. Pour les utilisateurs, cela signifie créer des documents avec des extensions de synonymes pour les attributs populaires et, pour les applications, inclure des mots-clés générés de manière heuristique en fonction des propriétés de l’application (comme l’ajout de « dépense » si l’application est Concur).
Couche d’intégration sur Amazon Bedrock
La couche d’intégration Cohere comprend une logique de nouvelle tentative et revient au modèle Titan dans certains scénarios. Les vecteurs en résultant encodent la signification du document sous forme numérique et sont normalisés à une longueur unitaire avant d’être stockés pour être utilisés avec la recherche dans l’index FAISS.
Classement hybride
Notre méthode de recherche hybride combine le signal sémantique de la recherche vectorielle avec une correspondance d’attributs plus traditionnelle. Pour chaque requête, l’étape de compréhension heuristique de la requête extrait des indices du texte fourni par l’utilisateur (comme le département ou la ville). Lors de l’étape de récupération des candidats, l’index FAISS est interrogé pour identifier les vecteurs les plus similaires. Les résultats se voient ensuite attribuer un score hybride qui combine la similarité vectorielle avec la présence d’attributs extraits. Enfin, les meilleurs candidats sont transmis au modèle Cohere Rerank, qui effectue le réordonnancement final.
Améliorations futures avec les LLM et les Event Hooks
Notre prototype de hackathon fonctionnait sur un instantané statique des données, mais pour en faire un système prêt pour la production, nous aurions besoin de deux améliorations : des données en temps réel et une méthode de recherche hybride utilisant des requêtes en direct.
Pour maintenir l’index à jour, nous remplacerions les instantanés périodiques par une architecture orientée événements utilisant les Event Hooks Okta. Une fonction sans serveur écouterait les événements syslog Okta et mettrait à jour la base de données vectorielle, garantissant ainsi que l’index de recherche ne soit que quelques secondes derrière les données en direct.
Ensuite, nous utiliserions des LLM (comme GPT ou Claude) pour interpréter la requête de l’utilisateur et générer un filtre SCIM précis qui serait ensuite exécuté sur l’API Okta. Cela permet de garantir la pertinence et l’exactitude des résultats.
Conclusion
La recherche sémantique Okta a commencé par une simple question : « Et si les administrateurs n’avaient plus jamais à écrire de filtre SCIM à la main ? ». En mettant en place un pipeline d’IA (indexation vectorielle, LLM et évaluation hybride), nous avons développé un prototype fonctionnel permettant aux administrateurs de rechercher des ressources Okta en langage naturel.
Si vous êtes un développeur souhaitant créer des systèmes d’IA pour résoudre des problèmes d’identité concrets, explorez les opportunités d’emploi sur notre page dédiée, ou lancez vos propres projets.
