Las limitaciones de búsqueda de la SCIM
Buscar usuarios en una organización Okta grande no es tan sencillo como parece. Si quiero encontrar a todos los proveedores de servicios de ventas en Los Ángeles, debo escribir la sintaxis de SCIM correctamente; de lo contrario, no obtendré los resultados esperados. Por ejemplo, para buscar usuarios por atributos de perfil, necesitaría algo como lo siguiente:
profile.department eq "Sales" and profile.city eq "Los Angeles" and profile.userType eq "Contractor"
Esta sintaxis es un desafío para muchos usuarios por los siguientes motivos:
- Tienen que conocer la sintaxis específica.
- La búsqueda se basa en palabras clave, por lo que una consulta como “mis subordinados directos” no encontrará la lista de usuarios subordinados al administrador actual. Si bien la consola de administración de Okta admite el filtrado por ID de gerente, la búsqueda habitual no comprende que “mis subordinados directos” debe traducirse a que profile.managerId equivale al ID del propio administrador.
- Un pequeño error tipográfico podría no arrojar resultados o arrojar resultados imprevistos.
En un hackatón interno reciente, intentamos responder una pregunta sencilla: ¿qué pasaría si los administradores de Okta pudieran simplemente escribir lo que quieren decir en lenguaje simple y dejar que el sistema descifrara los detalles de la SCIM? Entonces:
En lugar de | Podríamos usar |
|---|---|
search=profile.department eq "Sales" and profile.title eq "Manager" | Encontrar a los gerentes y directores de ventas |
profile.managerId eq "00u1ab2c3d4e" | Mostrar a todos los subordinados directos |
Para responder a esto, creamos un prototipo: un motor de búsqueda semántica impulsado por IA que interpreta el lenguaje natural, lo asigna a los recursos de Okta y devuelve los usuarios y aplicaciones pertinentes sin que el administrador tenga que usar ninguna sintaxis de SCIM. En el resto de este artículo, le mostraré cómo ensamblamos el prototipo y la visión de una futura implementación preparada para producción.
Flujo de trabajo general
Cuando un administrador de Okta escribe una consulta en lenguaje natural en la barra de búsqueda global, el backend de Java de Okta intercepta las llamadas a la API (/api/internal/admin/search y /api/v1/internal/apps). En lugar de ejecutar inmediatamente una consulta de SCIM estándar, realiza una llamada a la API del servicio de IA de Python con la consulta sin procesar del usuario.
El servicio de Python ejecuta su pipeline de búsqueda de varias etapas y devuelve una lista clasificada de ID de usuarios y aplicaciones pertinentes. El backend de Java toma esos ID, recupera los objetos de recursos completos de la capa de datos actual de Okta y construye la respuesta JSON final para que la IU la muestre.
Arquitectura del servicio de IA de Python
Capa de datos: para el prototipo, el servicio utiliza un proceso de indexación fuera de línea. Recupera usuarios y aplicaciones de una organización Okta de ejemplo, convierte estos recursos en instantáneas JSON locales y, luego, crea una representación de texto para la integración en la etapa final.
Capa de inteligencia de IA
- Servicio de integración: utilizamos modelos de integración de AWS Bedrock (por ejemplo, Cohere Embed o Amazon Titan) para asignar cada documento de texto a un vector. Esos vectores se almacenan en un índice FAISS (biblioteca de búsqueda de similitudes de IA de Facebook).
- Procesamiento de lenguaje natural: utilizamos LLM, como Anthropic Claude 4.5, para interpretar consultas y generar filtros de SCIM.
- Comprensión de consultas: un pequeño servicio de heurística extrae atributos estructurados (como “department”, “city” y “managerId”) de la consulta en lenguaje natural para refinar los resultados de búsqueda.
Pipeline de búsqueda avanzada
- Procesamiento de consultas: la consulta entrante se analiza, se amplía con sinónimos y se convierte en un vector.
- Recuperación de candidatos: buscamos en el índice FAISS los vectores más parecidos y asignamos a cada coincidencia una puntuación híbrida.
- Refinamiento de resultados: finalmente, enviamos los principales candidatos a un modelo Cohere Rerank para reordenarlos antes de devolver la lista final de ID de recursos.
Al utilizar el índice de vectores FAISS en este pipeline, reducimos el espacio de búsqueda de miles de usuarios y aplicaciones a un pequeño conjunto de candidatos. Esto reduce el tamaño del contexto que se pasa al modelo Rerank final, lo que reduce los costos operativos y la latencia.
Construir el conjunto de datos de forma segura
Usamos una organización Okta de ejemplo para evitar manipular cualquier dato de PII. Generamos perfiles aleatorios de usuarios y aplicaciones para llenar esta organización con datos realistas. Todos los datos se crearon mediante secuencias de comandos personalizadas de Python y se exportaron a archivos JSON locales. Esto nos permitió ejecutar el sistema sin conexión utilizando las instantáneas.
Convertir objetos de Okta en texto con capacidad de búsqueda
Los perfiles sin procesar de usuarios y aplicaciones no son suficientes para una buena búsqueda semántica. También necesitamos capturar todo su contexto e intención. Nuestro motor de indexación sin conexión gestiona esta preparación de datos antes de que se creen los vectores. En el caso de los objetos de Okta, los campos de texto clave se combinan primero en un único documento de texto para garantizar que el modelo de integración reciba una sola descripción para interpretar.
Luego, estos documentos se enriquecen abordando las limitaciones conocidas en los datos. Para los usuarios, significa crear documentos con expansiones de sinónimos para atributos frecuentes y, para las aplicaciones, incluir palabras clave generadas a partir de heurística y basadas en las propiedades de la aplicación (como agregar “expense” [gasto] si la aplicación es Concur).
Capa de integración en Amazon Bedrock
La capa de integración de Cohere incluye lógica de reintento y recurre al modelo Titan para ciertas situaciones. Los vectores generados codifican el significado del documento en forma numérica y se normalizan a una longitud de unidad antes de almacenarse para usarse con la búsqueda del índice FAISS.
Clasificación híbrida
Nuestro método de búsqueda híbrida combina la señal semántica de la búsqueda vectorial con la coincidencia de atributos más tradicional. Para cada consulta, el paso de comprensión heurística extrae sugerencias del texto proporcionado por el usuario (como el departamento o la ciudad). En la etapa de recuperación de candidatos, se consulta el índice FAISS para obtener los vectores más parecidos. A los resultados se les asigna una puntuación híbrida que combina la similitud de vectores con la presencia de atributos extraídos. Finalmente, los candidatos principales se transfieren al modelo Cohere Rerank, que realiza el reordenamiento final.
Mejoras futuras con LLM y hooks de eventos
Nuestro prototipo de hackatón se ejecutó en una instantánea estática de datos. Ahora bien, para convertirlo en un sistema preparado para producción, necesitaríamos dos mejoras: datos en tiempo real y un método de búsqueda híbrido que utilice consultas en vivo.
A fin de mantener el índice actualizado, reemplazaríamos las instantáneas periódicas con una arquitectura impulsada por eventos utilizando los hooks de eventos de Okta. Una función sin servidor escucharía los eventos de log de sistema de Okta y actualizaría la base de datos vectorial, lo que garantizaría que el índice de búsqueda esté apenas segundos detrás de los datos en vivo.
Después, usaríamos LLM (como GPT o Claude) para interpretar la consulta del usuario y generar un filtro de SCIM preciso que, luego, se ejecute directamente en la API de Okta en vivo. Con esto, los resultados serían precisos y estarían actualizados.
Conclusión
La búsqueda semántica de Okta comenzó con una simple pregunta: “¿qué pasaría si los administradores no tuvieran que escribir otro filtro de SCIM a mano?” Al crear un pipeline de IA (indexación vectorial, LLM y puntuación híbrida), desarrollamos un prototipo funcional que permite a los administradores buscar recursos de Okta en lenguaje sencillo.
Si es un desarrollador y le interesa crear sistemas de IA para resolver problemas de identidad del mundo real, conozca las oportunidades profesionales en la página de empleos de Okta o dé comienzo a sus propios proyectos.
