Einschränkungen bei der SCIM-Suche
Die Suche nach Benutzenden in einer großen Okta Org ist gar nicht so einfach. Möchte man beispielsweise alle vertrieblichen Auftragnehmenden in Los Angeles finden, muss die SCIM-Syntax exakt eingegeben werden, um die erwarteten Ergebnisse zu erhalten. Um Benutzende anhand von Profilattributen zu finden, benötigen Sie etwa Folgendes:
profile.department eq "Sales" and profile.city eq "Los Angeles" and profile.userType eq "Contractor"
Diese Syntax stellt für viele Benutzende eine Herausforderung dar, denn:
- Sie müssen die spezifische Syntax kennen.
- Die Suche basiert auf Schlüsselwörtern, daher werden mit einer Abfrage wie „meine direkt unterstellten Mitarbeitenden“ nicht die Benutzenden gefunden, dem aktuellen Admin unterstellt sind. Die Okta-Admin-Konsole unterstützt das Filtern nach Manager-ID, aber die reguläre Suche „versteht“ nicht, dass mit „meine direkt unterstellten Mitarbeitenden“ in profile.managerId die eigene ID des Admins gemeint ist.
- Ein kleiner Tippfehler genügt, damit gar keine oder unerwartete Ergebnisse ausgegeben werden.
Anlässlich eines kürzlich durchgeführten internen Hackathons haben wir versucht, eine einfache Frage zu beantworten: Was wäre, wenn Okta-Administrator:innen einfach in klar verständlicher Sprache eingeben könnten, was sie suchen, und das System die SCIM-Details automatisch herausfinden würde?
Jetzige Eingabe | Neue Eingabe |
|---|---|
search=profile.department eq "Sales" and profile.title eq "Manager" | Finde alle Sales Manager und Directors |
profile.managerId eq "00u1ab2c3d4e" | Zeige mir alle meine direkt unterstellten Mitarbeitenden |
Um diese Frage zu beantworten, haben wir einen Prototyp entwickelt: eine KI-gestützte semantische Suchmaschine, die natürliche Sprache interpretiert, sie mit Okta-Ressourcen abgleicht und relevante Benutzende und Anwendungen zurückgibt, ohne dass der Admin die SCIM-Syntax verwenden muss. Im verbleibenden Teil dieses Artikels zeige ich Ihnen, wie wir den Prototyp zusammengebaut haben, und ich stelle Ihnen die Vision für eine zukünftige, produktionsreife Implementierung vor.
Allgemeiner Workflow
Wenn ein Okta-Admin eine Abfrage in natürlicher Sprache in die globale Suchleiste eingibt, fängt das Java-Backend von Okta die API-Aufrufe ab (/api/internal/admin/search und /api/v1/internal/apps). Anstatt sofort eine Standard SCIM-Abfrage auszuführen, wird ein API-Aufruf an den Python-KI-Dienst mit der unbearbeiteten Abfrage der Benutzerin oder des Benutzers durchgeführt.
Der Python-Dienst führt seine mehrstufige Suchpipeline aus und gibt eine sortierte Liste relevanter Benutzer- und Anwendungs-IDs zurück. Das Java-Backend verwendet diese IDs, um die vollständigen Ressourcenobjekte aus der vorhandenen Okta-Datenebene abzurufen und die endgültige JSON-Antwort zu erstellen, die auf der Benutzeroberfläche angezeigt wird.
Architektur des Python-KI-Dienstes
Datenebene: Für den Prototyp verwendet der Dienst einen Offline-Indizierungsprozess. Dieser ruft Benutzende und Anwendungen aus einer Demo-Okta-Org ab, wandelt die Ressourcen in lokale JSON-Snapshots um und erstellt anschließend eine Textdarstellung für die nachgelagerte Einbettung.
KI-Intelligenzebene:
- Einbettungsdienst: Wir verwenden AWS Bedrock-Einbettungsmodelle (z. B. Cohere Embed, Amazon Titan), um jedes Textdokument in einen Vektor zu konvertieren. Diese Vektoren werden in einem FAISS-Index (Facebook AI Similarity Search-Bibliothek) gespeichert.
- Natural Language Processing: Wir verwenden LLMs wie Anthropic Claude 4.5, um Abfragen zu interpretieren und SCIM-Filter zu generieren.
- Abfrageverständnis: Ein kleiner heuristischer Dienst extrahiert strukturierte Attribute (wie Abteilung, Stadt und Manager-ID) aus der Abfrage in natürlicher Sprache, um die Suchergebnisse zu verfeinern.
Erweiterte Suchpipeline:
- Abfrageverarbeitung: Die eingehende Abfrage wird analysiert, um Synonyme erweitert und in einen Vektor umgewandelt.
- Kandidatenabruf: Wir durchsuchen den FAISS-Index nach den ähnlichsten Vektoren und weisen jedem Treffer eine hybride Bewertung zu.
- Ergebnisverfeinerung: Schließlich senden wir die besten Kandidat:innen an ein Cohere Rerank-Modell, um sie neu zu ordnen, bevor wir die endgültige Liste der Ressourcen-IDs zurückgeben.
Durch Verwenden des FAISS-Vektorindex in dieser Pipeline verengen wir den Suchraum von Tausenden Benutzenden und Anwendungen auf einen kleinen Kandidatensatz. Dadurch reduziert sich die Größe des an das finale Rerank-Modell übergebenen Kontexts, wodurch Betriebskosten und Latenz reduziert werden.
Sichere Erstellung des Datensatzes
Wir haben eine Demo-Okta-Org verwendet, um das Heranziehen personenbezogener Daten zu vermeiden. Wir haben zufällige Profile von Benutzenden und Anwendungen generiert, um die Org mit realistischen Daten zu füllen. Alle Daten wurden mit benutzerdefinierten Python-Skripten erstellt und in lokale JSON-Dateien exportiert. Dadurch konnten wir das System offline mit den Snapshots ausführen.
Konvertierung der Okta-Objekte in durchsuchbaren Text
Rohe Benutzer- und Anwendungsprofile reichen für eine effiziente semantische Suche nicht aus. Wir müssen auch den vollständigen Kontext und die Absicht erfassen. Diese Datenaufbereitung übernimmt unsere Offline-Indizierungs-Engine, noch bevor Vektoren erstellt werden. Für die Okta-Objekte werden die wichtigsten Textfelder zunächst in einem einzigen Textdokument zusammengeführt, um sicherzustellen, dass das Einbettungsmodell nur eine Beschreibung zur Interpretation erhält.
Diese Dokumente werden anschließend angereichert, indem bekannte Einschränkungen in den Daten behoben werden. Für Benutzende bedeutet dies, Dokumente mit Synonymerweiterungen für gängige Attribute zu erstellen und für Anwendungen, heuristisch generierte Schlüsselwörter basierend auf bestimmten Anwendungseigenschaften einzuschließen (z. B. „Aufwendung“, wenn die Anwendung Concur ist).
Einbettungsebene in Amazon Bedrock
Die Cohere-Einbettungsebene beinhaltet eine Wiederholungslogik und greift für bestimmte Szenarien auf das Titan-Modell zurück. Die resultierenden Vektoren kodieren die Bedeutung des Dokuments in numerischer Form. Die Dokumente werden vor dem Speichern auf eine Einheitslänge normalisiert, damit sie für die FAISS-Indexsuche verwendet werden können.
Hybride Rangfolge
Unsere hybride Suchmethode kombiniert das semantische Signal der Vektorsuche mit dem eher herkömmlichen Attributabgleich. Für jede Abfrage extrahiert der heuristische Schritt „Abfrageverständnis“ Hinweise aus dem vom Benutzer oder der von der Benutzer bereitgestellten Text (z. B. Abteilung oder Stadt). Im Schritt „Kandidatenabruf“ wird der FAISS-Index nach den ähnlichsten Vektoren durchsucht. Anschließend wird den Ergebnissen eine hybride Bewertung zugewiesen, die die Vektorähnlichkeit mit dem Vorhandensein extrahierter Attribute kombiniert. Abschließend werden die besten Kandidaten an das Cohere Rerank-Modell übergeben, das die endgültige Neuanordnung vornimmt.
Zukünftige Verbesserungen mit LLMs und Event-Hooks
Unser Hackathon-Prototyp wurde anhand eines statischen Snapshots der Daten ausgeführt. Doch um aus ihm ein produktionsreifes System zu machen, bräuchten wir zwei Verbesserungen: Echtzeitdaten und eine hybride Suchmethode mit Live-Abfragen.
Um den Index auf dem aktuellen Stand zu halten, müssten wir die regelmäßigen Snapshots durch eine ereignisgesteuerte Architektur mit Okta Event-Hooks ersetzen. Eine serverlose Funktion würde die Okta-Syslog-Ereignisse überwachen und die Vektordatenbank aktualisieren, um sicherzustellen, dass der Suchindex den Live-Daten mit nur wenigen Sekunden Abstand folgt.
Anschließend würden wir mithilfe von LLMs (wie GPT oder Claude) die Benutzerabfrage interpretieren und einen präzisen SCIM-Filter erzeugen, der dann direkt in der Live-Okta-API ausgeführt wird. Dadurch wird sichergestellt, dass die Ergebnisse aktuell und korrekt sind.
Fazit
Die semantische Suche von Okta begann mit einer einfachen Frage: „Was wäre, wenn Admins keinen weiteren SCIM-Filter von Hand schreiben müssten?“ Durch Zusammenstellen einer KI-Pipeline (Vektorindizierung, LLMs und hybride Bewertung) ist es gelungen, einen funktionsfähigen Prototyp zu erstellen, mit dem Administrator:innen in Klartext nach Okta-Ressourcen suchen können.
Wenn Sie uns bei der Entwicklung von KI-Systemen unterstützen und zur Behebung realer Identity-Probleme beitragen möchten, besuchen Sie die Karriereseite von Okta oder starten Sie Ihre eigenen Projekte.
