Accès et authentification
Les accès du cœur et ceux de l’API Business sont distincts. Faites préciser le mode du cœur déployé avant le premier appel.
API métier et exploitation
PARTICIPANT_API_SECURITY_MODE choisit le mode d’authentification de /api/v1/** :
| Mode | Comportement |
|---|---|
OFF | Développement local sans authentification sur ces routes. Le profil prod refuse ce mode. |
OIDC | Jeton Bearer vérifié par Keycloak, avec contrôle du royaume et des rôles. |
Valeurs par défaut du contrôle OIDC :
| Chemin | Royaume | Rôle |
|---|---|---|
/api/v1/{participantCode}/… | pi-<participantCode> | participant.client ou participant.ops |
Préfixes /operations/ et /pricing-engine/ du participant | pi-<participantCode> | participant.ops |
/api/v1/ops/… | pi-ops | participant.ops |
Ces paramètres peuvent être configurés par le déploiement. Un jeton absent ou rejeté reçoit 401. Un royaume ou un rôle non autorisé reçoit 403. Les en-têtes opérateur sont reconstruits depuis le jeton ; les renseigner soi-même ne crée aucun droit.
Authorization: Bearer <jeton fourni pour cet environnement>
Le portail propose un champ Bearer dans la référence. Le contrat exporté correspond à un assemblage local ; le mode réellement appliqué reste celui du serveur cible. Le portail ne provisionne ni utilisateur ni jeton.
Canal entrant de PI
Les callbacks reçoivent des messages XML signés de PI sur le canal mTLS prévu par le participant. L’identité du certificat et la destination du message sont contrôlées. Leur présence dans la référence ne les rend pas utilisables comme routes métier avec un simple jeton Bearer.
Essais depuis le navigateur
Les requêtes Scalar sont directes : aucun proxy tiers n’est configuré, et la conservation des accès Scalar est désactivée. Utilisez une origine autorisée par votre déploiement et une adresse HTTPS compatible avec celle du portail. Aucun élargissement des règles CORS ou de sécurité du cœur n’est requis pour lire la documentation.