Crear una cuenta técnica OAuth2 en IFS Cloud parece sencillo: obtener un Client ID y un Client Secret, asignar algunos Permission Sets y listo. En la práctica, en cuanto esa cuenta debe acceder a datos de HCM, se superponen varias capas de identidad: IAM Client, Service Account, IFS Service User y Person. Después de refrescar nuestro entorno UAT, esta cadena había quedado incoherente e IFS rechazaba la cuenta antes incluso de evaluar sus permisos. Esta es la configuración que finalmente funcionó en mi entorno IFS Cloud 25R2.

4 objetos distintos IAM Client, Service Account, IFS Service User y Person.
1 vínculo crítico El Directory ID conecta la identidad IAM con el usuario de aplicación IFS.
5 capas de acceso OAuth2, usuario IFS, Companies, Permission Sets y alcance de datos HCM.
1 error engañoso Login.FUSRNULL parece indicar que falta un permiso, pero el problema aparece antes en la cadena.

Un retorno de experiencia, no una regla universal

Este artículo describe una configuración utilizada realmente en un entorno IFS Cloud 25R2. Los nombres de las pantallas, las rutas de navegación y los mecanismos HCM pueden variar según la versión, los componentes instalados, los roles administrativos y las personalizaciones. Una Person no es obligatoria para todas las integraciones: en mi caso fue necesaria porque la cuenta debía estar autorizada sobre un alcance concreto de datos HCM.

01El verdadero problema: varias cadenas de identidad

Mi necesidad era bastante clásica: crear una cuenta técnica utilizable por un middleware, obtener un Client ID y un Client Secret, solicitar un token mediante el flujo OAuth2 Client Credentials y después llamar a las API REST de IFS necesarias para el módulo HCM.

La trampa consiste en creer que un único objeto de “cuenta API” asume todas esas responsabilidades. En realidad, IFS separa varios niveles: 

Aplicación externa
        │
        ▼
IAM Client
        │
        ▼
Service Account IAM
        │
        ▼
IFS Service User
        │
        ├── Companies
        ├── Permission Sets
        │
        ▼
Person
        │
        ▼
Alcance de datos HCM

Cada capa responde a una pregunta diferente:

  • ¿Quién solicita el token? El IAM Client.
  • ¿Qué identidad técnica lleva el token? El Service Account IAM.
  • ¿Qué usuario IFS ejecuta las llamadas? El IFS Service User.
  • ¿Qué funciones y proyecciones están autorizadas? Los Permission Sets.
  • ¿Qué Companies y qué datos de RR. HH. son visibles? Los accesos de sociedad y el alcance HCM asociado a la Person.

La frase que hay que recordar

IAM Client ≠ Service Account ≠ IFS Service User ≠ Person. Pueden tener nombres parecidos, pero no son el mismo objeto ni la misma capa de autorización.

02Por qué el refresco de UAT complicó la situación

En mi caso, el problema apareció después de refrescar el entorno UAT a partir de producción. La cuenta API existía anteriormente en UAT, pero no existía en el entorno de producción utilizado como origen del clonado.

Después del refresh, algunos componentes seguían presentes o habían sido recreados parcialmente, mientras que los vínculos entre IAM y los usuarios IFS ya no eran coherentes. 

IAM Client presente
+
Usuario IFS presente o recreado parcialmente
+
Directory ID ausente, incorrecto o asociado al objeto equivocado
=
token o conexión a la aplicación imposible

La API devolvía un error encapsulado bajo un código genérico como DB_ACCESS_ERROR, con el siguiente detalle: 

ORA-20105: Login.FUSRNULL:
The directory id SERVICE-ACCOUNT-... is not allowed to run the application.

El primer reflejo suele ser añadir más Permission Sets. En este caso concreto no sirve de nada: IFS todavía no ha llegado a la evaluación de los permisos funcionales. No consigue resolver correctamente la identidad IAM hacia el usuario de aplicación IFS.

No te dejes engañar por el mensaje principal

El mensaje global puede dar la impresión de un problema de base de datos o de autorización. El detalle Login.FUSRNULL indica sobre todo que hay que empezar por la cadena de identidad: Service Account User, Directory ID e IFS Service User.

03Los cuatro objetos que hay que distinguir

Objeto Función Qué no sustituye
IAM Client Representa la aplicación externa que solicita un token OAuth2. Por sí solo no contiene las Companies, los Permission Sets ni el alcance HCM.
Service Account IAM Identidad técnica creada cuando se activan los Service Accounts en el cliente. No sustituye al usuario de aplicación visible en la pantalla Users.
IFS Service User Usuario de aplicación al que se asignan los Permission Sets, las Companies y las autorizaciones IFS. No proporciona automáticamente un Client ID ni un Client Secret.
Person Objeto Person utilizado por determinados controles de datos y de organización de HCM. No sustituye al usuario IFS ni a sus Permission Sets.

04La trampa de los dos asistentes de creación

IFS ofrece dos rutas de creación que, por separado, parecen casi suficientes.

Ruta A: empezar desde Users

Desde la pantalla de usuarios IFS se puede crear un usuario de tipo Service User y asociarle una Person. Es muy práctico para HCM, pero no crea automáticamente el IAM Client, el Client ID y el Client Secret.

Ruta B: dejar que IAM cree el usuario

Desde IAM Clients, la opción de creación automática puede generar el Service User asociado. Es útil para muchas integraciones clásicas, pero en mi entorno el usuario generado no disponía de la Person necesaria para el alcance HCM. 

Creación desde Users
→ IFS Service User + Person
→ sin Client ID / Client Secret

Creación automática desde IAM Client
→ IAM Client + Service Account + IFS Service User
→ sin Person en mi caso

La solución elegida consiste por tanto en separar deliberadamente las dos operaciones:

El método que funcionó

Crear primero el IAM Client sin creación automática del Service User, recuperar el valor exacto del Service Account User y después crear manualmente el IFS Service User con su Person. El vínculo técnico se realiza mediante el Directory ID.

05La arquitectura objetivo que funciona

IAM Client: IFS_BLUEWAY
        │
        ├── Client ID
        ├── Client Secret
        └── Service Accounts = Yes
        │
        ▼
Service Account IAM
service-account-ifs_blueway
        │
        │ valor copiado en Directory ID
        ▼
IFS Service User: IFS_BLUEWAY
        │
        ├── User Type = Service User
        ├── Companies
        ├── Permission Sets
        └── Create Person = Yes
        │
        ▼
Person: IFS_BLUEWAY
        │
        ▼
HCM Organization Access

Copia el valor exacto

No reconstruyas el Directory ID a partir del nombre del cliente. Copia el valor realmente creado por IAM sin modificar los guiones, el prefijo ni las mayúsculas y minúsculas que muestre tu entorno.

06Paso 1: crear el IAM Client

En IFS Cloud 25R2, abre:

Solution Manager
→ Users and Permissions
→ Identity and Access Manager
→ IAM Clients

Crea un cliente dedicado a la integración, por ejemplo:

IFS_BLUEWAY

Para un escenario servidor a servidor, la configuración que utilicé fue la siguiente:

Parámetro de la interfaz Valor Motivo
Enabled Yes El cliente debe estar activo.
Public Client No El middleware es un cliente confidencial capaz de proteger un secreto.
Service Accounts Yes Activa la identidad técnica utilizada con Client Credentials.
Create IFS Service User No Permite crear después manualmente el Service User con una Person.

IFS crea entonces una identidad de cuenta de servicio parecida a:

service-account-ifs_blueway

Conserva tres datos: el Client ID, el Client Secret y el valor exacto de Service Account User.

El Client Secret es un secreto de producción

No lo incluyas en una captura de pantalla, un ticket, un log, un archivo de configuración versionado ni una colección Postman compartida. Guárdalo en un gestor de secretos o en el mecanismo seguro proporcionado por tu middleware.

07Paso 2: crear el IFS Service User y su Person

A continuación, abre:

Solution Manager
→ Users and Permissions
→ Users

Crea manualmente el usuario técnico. Ejemplo:

Identity      : IFS_BLUEWAY
User Type     : Service User
Directory ID  : service-account-ifs_blueway
Create Person : Yes

El campo esencial es Directory ID. Debe contener el valor exacto de Service Account User creado por el IAM Client.

El nombre de la Identity IFS puede seguir siendo legible para los administradores, pero el Directory ID es lo que establece el vínculo técnico: 

Token OAuth2
     │
     ▼
Service Account IAM
     │
     │ resolución mediante Directory ID
     ▼
IFS Service User
     │
     ▼
Permisos y datos autorizados

Comprueba también que el usuario esté activo, autorizado para ejecutar la aplicación y que su tipo sea realmente Service User.

08Por qué HCM puede requerir una Person

Un middleware no es, evidentemente, una persona física. Sin embargo, en IFS algunos mecanismos de autorización HCM se apoyan en el objeto Person y en su vínculo con un alcance organizativo.

Por tanto, hay que distinguir dos controles:

Control Pregunta a la que responde Ejemplo
Permiso funcional ¿Qué puede llamar este usuario? Acceso a una proyección REST o a una función IFS.
Autorización sobre datos HCM ¿Sobre qué datos puede actuar o leer? Alcance organizativo, empleados o unidades accesibles.

Una cuenta puede tener los Permission Sets necesarios y seguir recibiendo un error o un resultado vacío sobre determinados datos HCM si la Person asociada no tiene el alcance correcto.

09Paso 3: asignar Companies

Según la configuración, el acceso a las sociedades se gestiona, entre otros lugares, desde:

Accounting Rules
→ User Related Data
→ Users per Company

Añade la cuenta técnica a cada Company cuyos datos deba leer o procesar el middleware. No concedas automáticamente acceso a todas las Companies: conserva el principio de mínimo privilegio.

10Paso 4: asignar Permission Sets

A continuación, asigna los Permission Sets necesarios para las proyecciones REST y las funciones utilizadas realmente por el middleware.

Un Permission Set no significa acceso HCM ilimitado

Los Permission Sets habilitan funciones y proyecciones. Los controles HCM todavía pueden filtrar los datos según la Person, la organización, la Company y el contexto de negocio.

Para diagnosticar correctamente, empieza con el conjunto mínimo de Permission Sets necesario para una proyección de prueba y añade después los derechos por funcionalidad. Asignar inmediatamente un perfil muy amplio oculta el problema real y aumenta el riesgo de seguridad.

11Paso 5: asignar el alcance HCM

La estructura organizativa está disponible, entre otros lugares, desde:

Human Capital Management
→ HCM Services
→ Organization Management
→ Graphical Organization Structure

Comprueba el alcance al que debe acceder la Person de la cuenta técnica. La configuración adecuada depende de la necesidad: toda la organización, determinadas unidades o un perímetro más restringido.

La cadena completa queda entonces así:

IAM Client
     │
     ▼
Service Account IAM
     │
     ▼
IFS Service User
     ├── Companies
     ├── Permission Sets
     │
     ▼
Person
     │
     ▼
HCM Organization Access

12Probar OAuth2 y la API por capas

Una vez terminada la configuración, el middleware puede utilizar el flujo OAuth2 Client Credentials. 

Client ID + Client Secret
          │
          ▼
Endpoint OAuth2 IFS
          │
          ▼
Access Token
          │
          ▼
Authorization: Bearer <token>
          │
          ▼
Proyección REST IFS

Para no mezclar varios problemas, realiza las pruebas en este orden:

  1. Obtener un token con el Client ID y el Client Secret.
  2. Llamar a una proyección sencilla que requiera pocos permisos.
  3. Probar el acceso a Company sobre un dato que no sea HCM.
  4. Probar la proyección HCM objetivo.
  5. Comparar el resultado esperado con el alcance de la Person.

Ejemplo genérico que debes adaptar con el endpoint OAuth2 real de tu entorno:

curl -X POST "<IFS_TOKEN_ENDPOINT>" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=<CLIENT_ID>" \
  -d "client_secret=<CLIENT_SECRET>"

No registres la orden completa en los logs

En un script de explotación, el secreto debe proceder de una variable protegida o de un gestor de secretos. Evita también que aparezca en el historial del shell.

13Matriz de diagnóstico de errores

La tabla siguiente es un método práctico de diagnóstico, no una lista oficial exhaustiva de errores IFS.

Síntoma Capa que hay que revisar primero Comprobaciones útiles
No se emite el token IAM Client y OAuth2 Cliente activo, secreto válido, grant autorizado, endpoint y entorno correctos.
Login.FUSRNULL o Directory ID no autorizado Vínculo IAM hacia IFS User Service Account User exacto, Directory ID, usuario activo, tipo Service User y duplicados.
Token válido pero respuesta 401/403 en una proyección Permission Sets y proyección Derechos de la proyección, usuario IFS objetivo y activación del Permission Set.
La API responde pero faltan algunas Companies Users per Company Companies asignadas a la cuenta y contexto de Company esperado.
La API HCM devuelve pocos datos o ninguno Person y alcance HCM Person creada, vínculo usuario-Person, organización y autorizaciones HCM.
La cuenta funcionaba antes de un refresh Coherencia entre entornos IAM Client, Service Account User, Directory ID, secreto, Person y derechos recreados.

El error FUSRNULL: la comprobación prioritaria

Service Account User IAM
            =
Directory ID del IFS Service User

Después, comprueba:

  • El Service User está activo.
  • Su tipo es realmente Service User.
  • Está autorizado para ejecutar la aplicación IFS.
  • El Directory ID coincide exactamente con la identidad IAM.
  • Ningún otro usuario tiene el mismo Directory ID.
  • La prueba utiliza el entorno y el Client ID correctos.

14Checklist después de clonar un entorno

Después de un clonado de PROD hacia UAT, un refresh de TEST o cualquier operación de sustitución de entorno, ver un usuario en la interfaz no garantiza la coherencia de toda su cadena de identidad.

  • IAM Client: ¿existe en el entorno objetivo y está activo?
  • Client ID: ¿el middleware utiliza el correspondiente al entorno objetivo?
  • Client Secret: ¿sigue siendo válido y está guardado en el lugar correcto?
  • Service Account User: ¿qué valor exacto creó IAM?
  • IFS Service User: ¿existe, está activo y tiene el tipo correcto?
  • Directory ID: ¿coincide exactamente con el Service Account User?
  • Person: ¿existe y está vinculada al usuario correcto?
  • Companies: ¿están asignadas las Companies necesarias?
  • Permission Sets: ¿están autorizadas las proyecciones objetivo?
  • HCM Access: ¿sigue presente el alcance organizativo?

Automatiza esta checklist siempre que sea posible

Para las integraciones críticas, conserva un expediente de explotación por entorno con los nombres de los objetos, las pruebas de salud, las proyecciones utilizadas y el procedimiento de recreación. Evidentemente, el secreto nunca debe documentarse en texto plano.

15Seguridad y explotación de la cuenta técnica

Algunas buenas prácticas generales completan la configuración:

  • Un cliente por integración y por entorno: evita compartir el mismo Client ID entre varios middleware o entre PROD y UAT.
  • Mínimo privilegio: asigna únicamente las Companies, proyecciones y alcances HCM necesarios.
  • Rotación del secreto: documenta el procedimiento de renovación y de actualización del middleware.
  • Trazabilidad: utiliza un nombre técnico identificable en los logs y auditorías.
  • Pruebas de salud: verifica regularmente la emisión del token y después llama a una proyección no destructiva.
  • Sin conexión interactiva: un Service User destinado a integración no debe convertirse en una cuenta humana genérica.
  • Revocación controlada: conoce qué flujo quedará afectado antes de desactivar el cliente o el Service User.

Una cuenta HCM es especialmente sensible

Los datos de RR. HH. pueden contener información personal y confidencial. Una cuenta técnica con derechos HCM debe estar supervisada, limitada a los datos necesarios y utilizada únicamente por el middleware previsto.

16Configuración final y checklist rápida

La configuración funcional obtenida en mi entorno es la siguiente:

IAM Client: IFS_BLUEWAY
     ├── Enabled = Yes
     ├── Public Client = No
     ├── Service Accounts = Yes
     ├── Create IFS Service User = No
     ├── Client ID
     └── Client Secret
             │
             ▼
Service Account User IAM
service-account-ifs_blueway
             │
             │ Directory ID
             ▼
IFS Service User: IFS_BLUEWAY
     ├── User Type = Service User
     ├── Active
     ├── Companies
     ├── Permission Sets
     └── Person creada
             │
             ▼
Person: IFS_BLUEWAY
     └── Autorizaciones HCM

La secuencia de creación que hay que recordar:

1. Crear el IAM Client.
2. Activar Service Accounts.
3. No solicitar la creación automática del Service User.
4. Copiar el valor exacto del Service Account User.
5. Crear manualmente el IFS Service User.
6. Utilizar el Service Account User como Directory ID.
7. Crear la Person asociada.
8. Asignar Companies.
9. Asignar Permission Sets.
10. Asignar el alcance HCM.
11. Probar el token y después las API por capas.

Lo esencial

  • Un IAM Client, un Service Account IAM, un IFS Service User y una Person son objetos diferentes.
  • El Directory ID es el vínculo crítico entre la identidad IAM y el usuario de aplicación IFS.
  • En este escenario HCM, el IAM Client y el Service User deben crearse manualmente en dos operaciones.
  • La opción Create IFS Service User debe permanecer en No para poder crear después la Person.
  • Los Permission Sets autorizan funciones, pero no garantizan por sí solos el acceso a los datos HCM.
  • El error Login.FUSRNULL debe orientar primero el diagnóstico hacia el Directory ID y la resolución del usuario.
  • Después de clonar un entorno, hay que revisar de nuevo toda la cadena IAM → IFS User → Person.
  • El Client Secret debe protegerse como una contraseña y separarse por entorno.

Alcance del artículo

Este artículo es un retorno de experiencia técnico realizado sobre IFS Cloud 25R2. No constituye documentación oficial de IFS. Las pantallas, opciones y reglas de autorización pueden evolucionar o ser diferentes en tu instalación.

Los nombres IFS_BLUEWAY, service-account-ifs_blueway, los Client ID y los endpoints son ejemplos. Nunca incluyas un Client Secret real en un artículo, un repositorio Git, un ticket o una captura de pantalla.