IFS Cloud 25R2 : créer un compte API avec IAM Client, Service User et Person pour HCM

Créer un compte technique OAuth2 dans IFS Cloud paraît simple : un Client ID, un Client Secret, quelques Permission Sets et le tour est joué. En pratique, dès que ce compte doit accéder à des données HCM, plusieurs couches d’identité se superposent : IAM Client, Service Account, IFS Service User et Person. Après un rafraîchissement de notre environnement UAT, cette chaîne était devenue incohérente et IFS refusait le compte avant même d’évaluer ses permissions. Voici la configuration qui a finalement fonctionné dans mon environnement IFS Cloud 25R2.

01Le vrai problème : plusieurs chaînes d’identité

Mon besoin était pourtant classique : créer un compte technique utilisable par un middleware, obtenir un Client ID et un Client Secret, demander un token avec le flux OAuth2 Client Credentials, puis appeler les API REST IFS nécessaires au module HCM.

Le piège est de croire qu’un seul objet « compte API » porte toutes ces responsabilités. IFS sépare en réalité plusieurs niveaux :

Application externe
        │
        ▼
IAM Client
        │
        ▼
Service Account IAM
        │
        ▼
IFS Service User
        │
        ├── Companies
        ├── Permission Sets
        │
        ▼
Person
        │
        ▼
Périmètre de données HCM

Chaque couche répond à une question différente :

• Qui demande le token ? L’IAM Client.
• Quelle identité technique porte le token ? Le Service Account IAM.
• Quel utilisateur IFS exécute les appels ? L’IFS Service User.
• Quelles fonctions et projections sont autorisées ? Les Permission Sets.
• Quelles sociétés et quelles données RH sont visibles ? Les accès société et le périmètre HCM associé à la Person.

02Pourquoi le rafraîchissement UAT a compliqué la situation

Dans mon cas, le problème est apparu après un rafraîchissement de l’environnement UAT à partir de la production. Le compte API existait auparavant en UAT, mais pas dans la production ayant servi de source au clonage.

Après le refresh, certaines briques existaient toujours ou avaient été partiellement recréées, alors que les liaisons entre IAM et les utilisateurs IFS n’étaient plus cohérentes.

IAM Client présent
+
Utilisateur IFS présent ou recréé partiellement
+
Directory ID absent, incorrect ou associé au mauvais objet
=
token ou connexion applicative impossible

L’API renvoyait notamment une erreur encapsulée sous un code générique de type DB_ACCESS_ERROR, avec le détail suivant :

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

Le premier réflexe est souvent d’ajouter des Permission Sets. Dans ce cas précis, cela ne sert à rien : IFS n’est pas encore arrivé à l’évaluation des permissions fonctionnelles. Il ne parvient pas à résoudre correctement l’identité IAM vers l’utilisateur applicatif IFS.

03Les quatre objets à distinguer

04Le piège des deux assistants de création

IFS propose deux chemins de création qui semblent chacun presque suffisants.

Création depuis Users
→ IFS Service User + Person
→ pas de Client ID / Client Secret

Création automatique depuis IAM Client
→ IAM Client + Service Account + IFS Service User
→ pas de Person dans mon cas

La méthode retenue consiste donc à séparer volontairement les deux opérations :

05L’architecture cible qui fonctionne

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

06Étape 1 : créer l’IAM Client

Dans IFS Cloud 25R2, ouvrez :

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

Créez un client dédié à l’intégration, par exemple :

IFS_BLUEWAY

Pour un scénario serveur à serveur, la configuration utilisée dans mon cas est la suivante :

IFS crée alors une identité de compte de service ressemblant à :

service-account-ifs_blueway

Conservez trois informations : le Client ID, le Client Secret et la valeur exacte du Service Account User.

07Étape 2 : créer le Service User IFS et sa Person

Ouvrez ensuite :

Solution Manager
→ Users and Permissions
→ Users

Créez manuellement l’utilisateur technique. Exemple :

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

Le champ essentiel est Directory ID. Il doit contenir la valeur exacte du Service Account User créé par l’IAM Client.

Le nom de l’Identity IFS peut rester lisible pour les administrateurs, mais c’est le Directory ID qui réalise la liaison technique :

Token OAuth2
     │
     ▼
Service Account IAM
     │
     │ résolution par Directory ID
     ▼
IFS Service User
     │
     ▼
Permissions et données autorisées

Vérifiez également que l’utilisateur est actif, qu’il est autorisé à exécuter l’application et que le type est bien Service User.

08Pourquoi HCM peut nécessiter une Person

Un middleware n’est évidemment pas une personne physique. Pourtant, dans IFS, certains mécanismes d’autorisation HCM s’appuient sur l’objet Person et sur son rattachement au périmètre organisationnel.

Il faut donc distinguer deux contrôles :

Un compte peut donc posséder les Permission Sets nécessaires et continuer à recevoir une erreur ou un résultat vide sur certaines données HCM si la Person associée n’a pas le bon périmètre.

09Étape 3 : attribuer les sociétés

Selon la configuration, l’accès société se gère notamment depuis :

Accounting Rules
→ User Related Data
→ Users per Company

Ajoutez le compte technique à chaque société dont le middleware doit lire ou traiter les données. Ne donnez pas automatiquement toutes les sociétés : conservez le principe du moindre privilège.

10Étape 4 : attribuer les Permission Sets

Attribuez ensuite les Permission Sets nécessaires aux projections REST et aux fonctions réellement utilisées par le middleware.

Pour diagnostiquer proprement, commencez par le jeu minimal de Permission Sets nécessaire à une projection de test, puis ajoutez les droits par fonctionnalité. Attribuer immédiatement un profil très large masque le problème et augmente le risque de sécurité.

11Étape 5 : attribuer le périmètre HCM

La structure organisationnelle est accessible notamment depuis :

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

Contrôlez le périmètre auquel la Person du compte technique doit accéder. Le bon réglage dépend du besoin : toute l’organisation, certaines unités ou un périmètre plus restreint.

La chaîne complète devient alors :

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

12Tester OAuth2 et l’API par couches

Une fois la configuration terminée, le middleware peut utiliser le flux OAuth2 Client Credentials.

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

Pour éviter de mélanger plusieurs problèmes, testez dans cet ordre :

1. Obtenir un token avec le Client ID et le Client Secret.
2. Appeler une projection simple nécessitant peu de droits.
3. Tester l’accès société sur une donnée non HCM.
4. Tester la projection HCM cible.
5. Comparer le résultat attendu avec le périmètre de la Person.

Exemple générique à adapter avec l’endpoint OAuth2 réel de votre environnement :

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>"

13Grille de diagnostic des erreurs

La grille suivante est une méthode pratique de diagnostic, pas une table officielle exhaustive des erreurs IFS.

L’erreur FUSRNULL : la vérification prioritaire

Service Account User IAM
            =
Directory ID du Service User IFS

Puis contrôlez :

• Le Service User est actif.
• Son type est bien Service User.
• La connexion à l’application IFS est autorisée.
• Le Directory ID correspond exactement à l’identité IAM.
• Aucun autre utilisateur ne possède le même Directory ID.
• Le test est réalisé dans le bon environnement avec le bon Client ID.

14Checklist après un clonage d’environnement

Après un clonage de PROD vers UAT, un refresh de TEST ou toute opération de remplacement d’environnement, l’existence visuelle d’un utilisateur ne garantit pas la cohérence de toute sa chaîne d’identité.

• IAM Client : existe-t-il dans l’environnement cible et est-il actif ?
• Client ID : le middleware utilise-t-il celui de l’environnement cible ?
• Client Secret : est-il toujours valide et stocké au bon endroit ?
• Service Account User : quelle valeur exacte IAM a-t-il créée ?
• IFS Service User : existe-t-il, est-il actif et du bon type ?
• Directory ID : correspond-il exactement au Service Account User ?
• Person : existe-t-elle et est-elle liée au bon utilisateur ?
• Companies : les sociétés nécessaires sont-elles attribuées ?
• Permission Sets : les projections cibles sont-elles autorisées ?
• HCM Access : le périmètre organisationnel est-il toujours présent ?

15Sécurité et exploitation du compte technique

Quelques bonnes pratiques générales complètent la configuration :

• Un client par intégration et par environnement : évitez de partager le même Client ID entre plusieurs middlewares ou entre PROD et UAT.
• Moindre privilège : attribuez uniquement les sociétés, projections et périmètres HCM nécessaires.
• Rotation du secret : documentez la procédure de renouvellement et la mise à jour du middleware.
• Traçabilité : utilisez un nom technique identifiable dans les logs et les audits.
• Tests de santé : vérifiez régulièrement le token puis une projection non destructive.
• Aucune connexion interactive : un Service User destiné à l’intégration ne doit pas devenir un compte humain générique.
• Révocation maîtrisée : sachez quel flux sera impacté avant de désactiver le client ou le Service User.

16Configuration finale et checklist rapide

La configuration fonctionnelle obtenue dans mon environnement ressemble à ceci :

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 créée
             │
             ▼
Person : IFS_BLUEWAY
     └── Autorisations HCM

La séquence de création à retenir :

1. Créer l’IAM Client.
2. Activer Service Accounts.
3. Ne pas demander la création automatique du Service User.
4. Copier la valeur exacte du Service Account User.
5. Créer manuellement l’IFS Service User.
6. Utiliser le Service Account User comme Directory ID.
7. Créer la Person associée.
8. Attribuer les sociétés.
9. Attribuer les Permission Sets.
10. Attribuer le périmètre HCM.
11. Tester le token puis les API par couches.