SSO sous Immersive

• Type non défini

Configuration

Cette documentation décrit la configuration du SSO de RestFrontage, le rattachement des comptes Immersive et les parcours SAML 2.0 et OpenID. Elle s’adresse aux administrateurs Immersive, aux responsables de fédération d’identités et aux intégrateurs des applications clientes.

1. Comprendre le SSO dans Immersive

Le Single Sign-On, ou SSO, permet à un utilisateur de s’authentifier auprès d’un fournisseur d’identité externe, puis d’accéder à une application Immersive. Le fournisseur d’identité, appelé IdP, gère la connexion et peut appliquer ses propres exigences, par exemple une authentification multifacteur.

RestFrontage retrouve ensuite un compte Immersive à partir de l’identité externe, vérifie l’état de ce compte et émet un jeton d’authentification Immersive. Les droits utilisés par l’application restent ceux du compte, de ses groupes et de ses habilitations dans Immersive.

1.1 Les trois éléments à distinguer

Élément	Rôle
Identité externe	Identifie la personne auprès de l’IdP. Elle doit pouvoir être rapprochée d’un compte Immersive.
Compte Immersive	Porte l’état du compte et ses droits sur les objets et les fonctions de la plateforme.
Jeton Immersive	Est retourné par RestFrontage après l’authentification et sert aux échanges suivants avec l’API. Sa durée dépend de la configuration de l’application.

Le jeton d’accès de l’IdP, la réponse SAML et le jeton Immersive sont des éléments différents. Une authentification réussie chez l’IdP ne suffit pas à accorder des droits dans Immersive.

flowchart TD
    A["Authentification auprès du fournisseur d’identité"] --> B["Identité externe"]
    B --> C{"Compte Immersive correspondant ?"}
    C -->|"Non"| X["Connexion refusée"]
    C -->|"Oui"| D{"Compte activé, non expiré et non verrouillé ?"}
    D -->|"Non"| X
    D -->|"Oui"| E["Émission d’un jeton Immersive"]
    E --> F["Accès selon les droits du compte et de ses groupes"]

1.2 Les deux parcours disponibles

RestFrontage propose deux parcours d’authentification externe : SAML et OpenID. Ils permettent tous deux de retrouver un compte Immersive existant, de vérifier son état et de délivrer un jeton Immersive. Les droits restent ceux du compte et de ses groupes.

Ces parcours diffèrent par la manière dont le client et RestFrontage échangent avec le fournisseur d’identité :

Étape de la connexion	Avec SAML	Avec OpenID
Démarrer l’authentification externe	Le client demande à RestFrontage une URL SAML, puis ouvre la page de connexion du fournisseur d’identité.	Le client s’authentifie auprès du fournisseur d’identité pour obtenir un jeton d’accès externe.
Transmettre le résultat à RestFrontage	Le navigateur transmet une réponse SAML XML à RestFrontage.	Le client transmet le jeton d’accès externe à RestFrontage.
Identifier le compte externe	RestFrontage lit l’attribut de compte dans la réponse SAML.	RestFrontage appelle tokeninfo puis userinfo et lit la propriété login.
Terminer la connexion Immersive	Le client échange l’identifiant de demande SAML contre un jeton Immersive, après vérification du compte.	RestFrontage délivre un jeton Immersive après les appels au fournisseur d’identité et la vérification du compte.

Lorsque le fournisseur d’identité et l’application cliente sont compatibles avec les parcours pris en charge, le raccordement s’effectue par configuration de RestFrontage, du fournisseur d’identité et du client, puis par rattachement des comptes Immersive. Aucun développement spécifique de connexion n’est alors nécessaire. Une adaptation peut toutefois être requise si les échanges attendus ou les exigences de sécurité du déploiement ne sont pas couverts par l’implémentation.

1.2.1 Correspondance avec le compte Immersive

RestFrontage utilise le nom de compte reçu du fournisseur d’identité pour rechercher un utilisateur Immersive. Cette valeur doit correspondre au champ Nom de compte de rattachement externe, appelé AssociatedExternalUserAccountName dans le modèle.

Avec SAML, la valeur provient d’un attribut de la réponse XML envoyée par le fournisseur d’identité. RestFrontage recherche d’abord l’attribut nommé cn. S’il est absent, il recherche l’attribut nommé http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name.

L’administrateur du fournisseur d’identité configure les attributs transmis pour l’application Immersive. Le nom cn désigne ici un attribut de la réponse SAML : RestFrontage ne va pas chercher cette valeur directement dans un annuaire. Le champ SAML NameID n’est pas utilisé pour retrouver le compte Immersive.

Avec OpenID, la valeur provient de la propriété login du document JSON retourné par le service userinfo du fournisseur d’identité.

Par exemple, si le compte Immersive possède agent.demo comme nom de compte de rattachement externe, l’attribut SAML retenu ou la propriété OpenID login doit contenir agent.demo.

1.2.2 Routes définies dans RestFrontage

Les chemins suivants sont définis dans l’application. Ils sont relatifs à l’adresse de base sous laquelle RestFrontage est publié.

Fonction	Méthode et chemin relatif
Obtenir l’URL de connexion SAML	GET /api/Saml/GetSamlUrl
Recevoir la réponse de connexion SAML	POST /api/Saml/Login
Obtenir le jeton Immersive après le retour SAML	POST /api/Saml/Authenticate
Obtenir l’URL de déconnexion SAML	GET /api/Saml/GetSamlLogoutUrl
Recevoir le retour de déconnexion SAML	GET ou POST /api/Saml/Logout
Vérifier le jeton externe auprès des services OpenID	GET /api/OpenID/CheckToken
Obtenir le jeton Immersive à partir du jeton externe	POST /api/OpenID/Authenticate

Le contrôleur OpenID ne définit pas de route pour ouvrir la connexion chez le fournisseur d’identité ni pour effectuer une déconnexion fédérée. Ces opérations dépendent de l’intégration du client avec le fournisseur d’identité.

Le retour de déconnexion SAML ne révoque pas explicitement les jetons Immersive dans la méthode examinée. La fermeture de la session chez le fournisseur d’identité et la fin des accès Immersive sont donc à vérifier séparément.

1.2.3 Sections de configuration du serveur

Saml et OpenID sont des sections de la configuration de l’application RestFrontage, placées à la racine du fichier de configuration du Rest Frontage appsettings.json. Leurs valeurs peuvent aussi être fournies par les variables d’environnement de l’hébergement.

• La section Saml contient les adresses du fournisseur d’identité, l’identifiant du service Immersive et les URL publiques de retour vers RestFrontage.
• La section OpenID contient notamment l’adresse de base des services tokeninfo et userinfo et l’identifiant de l’application attendu par RestFrontage.

Les paramètres SAML LoginUrl et LogoutUrl indiquent les URL publiques qui conduisent aux routes /api/Saml/Login et /api/Saml/Logout. Ils ne créent pas de nouvelles routes.

1.2.4 Parcours SAML

Le fournisseur d’identité transmet une réponse SAML par le navigateur. Le client échange ensuite l’identifiant de cette connexion contre un jeton Immersive. Le schéma présente le parcours lorsque toutes les étapes réussissent.

sequenceDiagram
    participant C as Client et navigateur
    participant R as RestFrontage
    participant I as Fournisseur d’identité

    C->>R: Demander l’URL de connexion SAML
    R-->>C: URL de connexion
    C->>I: Ouvrir la connexion et s’authentifier
    I-->>C: Réponse SAML
    C->>R: Transmettre la réponse SAML
    R->>R: Retrouver le compte externe et mémoriser la demande
    R-->>C: Retour de connexion
    C->>R: Envoyer l’identifiant de demande chiffré
    R->>R: Retrouver la demande et vérifier l’état du compte
    R-->>C: Jeton Immersive et utilisateur

1.2.5 Parcours OpenID

Le client obtient d’abord un jeton d’accès externe. RestFrontage interroge ensuite les services du fournisseur d’identité pour retrouver le compte Immersive. Le schéma présente le parcours spécifique de cette version, lorsque toutes les étapes réussissent.

sequenceDiagram
    participant C as Client Immersive
    participant R as RestFrontage
    participant I as Fournisseur d’identité

    C->>I: S’authentifier et obtenir un jeton d’accès
    I-->>C: Jeton d’accès externe
    C->>R: Envoyer le jeton externe chiffré
    R->>I: Appeler tokeninfo
    I-->>R: client_id, access_token et realm
    R->>R: Comparer client_id avec FidAppId
    R->>I: Appeler userinfo avec le jeton retourné
    I-->>R: Identité contenant login
    R->>R: Retrouver le compte Immersive à partir de login
    R->>R: Vérifier l’état du compte
    R-->>C: Jeton Immersive et utilisateur

2. Préparer le raccordement

2.1 Informations à réunir

Information	À obtenir auprès de
URL publique HTTPS de RestFrontage, y compris un éventuel préfixe de chemin	Équipe exploitant Immersive.
URL de l’application cliente et parcours de connexion attendu	Équipe exploitant Immersive.
Environnement cible et accès réseau autorisés	Équipes d’exploitation et réseau.
Identifiant externe stable de l’utilisateur pilote	Équipe identité.
URL et paramètres SAML, ou contrat des services OpenID	Administrateur de l’IdP.
Compte Immersive pilote, groupes et droits nécessaires	Administrateur Immersive.

Pour SAML, le navigateur doit pouvoir joindre l’IdP puis transmettre la réponse à l’URL publique de RestFrontage. Pour OpenID, RestFrontage doit aussi pouvoir appeler directement les services tokeninfo et userinfo de l’IdP.

Conserver un accès d’administration opérationnel pendant la recette. Utiliser un environnement de validation et un compte pilote avant de généraliser le raccordement.

2.2 Emplacement de la configuration

Les sections Saml et OpenID sont chargées au démarrage de RestFrontage. Elles peuvent être renseignées dans les fichiers de configuration de l’environnement ou par les variables d’environnement du processus.

Les services SAML et OpenID conservent les options reçues lors de leur création. Redémarrer l’instance RestFrontage après une modification de ces options, même si le fournisseur de configuration sait recharger un fichier.

Exemples de noms de variables d’environnement :

Saml__FidUrl
Saml__FidSsoPath
Saml__FidSloPath
Saml__EntityId
Saml__LoginUrl
Saml__LogoutUrl
OpenID__FidUrl
OpenID__FidAppId
OpenID__FidAppSecret

Exemple appsettings.json sur ces deux sections :

  "Saml": {
    "FidUrl": "???",
    "EntityId": "???",
    "LoginUrl": "???/api/Saml/Login",
    "LogoutUrl": "???/api/Saml/Logout"
  },
  "OpenID": {
    "FidUrl": "???",
    "FidAppId": "???",
    "FidAppSecret": "???"
  }

3. Rattacher les utilisateurs externes

3.1 Configurer la fiche utilisateur

1. Ouvrir la fiche du compte dans la gestion des utilisateurs de sécurité de RestFrontage.
2. Repérer le bloc Interopérabilité et ouvrir Gérer l’interopérabilité.
3. Renseigner Domaine de rattachement externe pour décrire le domaine d’origine du compte.
4. Renseigner Nom de compte de rattachement externe avec la valeur exacte attendue de l’IdP.
5. Enregistrer la fiche, puis vérifier que le compte est activé et que ses groupes et droits sont corrects.

Champ	Propriété	Utilisation dans les parcours examinés
Domaine de rattachement externe	AssociatedExternalUserDomain	Champ disponible dans la fiche ; il n’est pas utilisé par les recherches de compte SAML et OpenID examinées.
Nom de compte de rattachement externe	AssociatedExternalUserAccountName	Clé de rapprochement utilisée pour retrouver l’utilisateur Immersive.

Exemple de correspondance à préparer :

Donnée	Exemple
Nom du compte Immersive	operateur.pilote
Domaine externe renseigné	ENTREPRISE
Nom de compte externe renseigné	agent.demo
Valeur cn reçue en SAML	agent.demo
Valeur login reçue en OpenID	agent.demo

Le compte local et le compte externe peuvent porter des noms différents. En revanche, la valeur reçue de l’IdP doit correspondre au champ de rattachement externe. Reprendre exactement sa casse et ses caractères : le code n’effectue pas de normalisation commune, et la sensibilité de certaines recherches SAML dépend aussi de la base de données.

3.2 Conditions d’accès du compte Immersive

Le compte doit déjà exister. Aucun provisionnement automatique d’utilisateur ou de groupe à partir des attributs SAML ou OpenID n’apparaît dans ces parcours.

L’émission du jeton Immersive est refusée lorsque le compte est désactivé, expiré ou encore verrouillé. Les contrôleurs vérifient notamment IsEnabled, ExpirationDate et LockoutUntilUtc. Un compte arrivé à expiration est désactivé dans le parcours d’authentification.

Les rôles ou groupes transmis par l’IdP ne sont pas transformés automatiquement en droits Immersive par ces contrôleurs. Affecter les droits au compte ou à ses groupes dans Immersive et les vérifier après connexion.

4. Configurer SAML

4.1 Paramètres RestFrontage

Paramètre	Rôle	Exemple fictif
Saml:FidUrl	Base de l’URL du fournisseur d’identité.	https://idp.example.net
Saml:FidSsoPath	Chemin ajouté à FidUrl pour la connexion.	/saml/sso
Saml:FidSloPath	Chemin ajouté à FidUrl pour la déconnexion fédérée.	/saml/slo
Saml:EntityId	Identifiant du service Immersive déclaré auprès de l’IdP et placé dans Issuer.	urn:example:immersive:recette
Saml:LoginUrl	URL publique de réception de la réponse de connexion, ou ACS.	https://rest.example.net/api/Saml/Login
Saml:LogoutUrl	URL publique de retour de déconnexion.	https://rest.example.net/api/Saml/Logout

Le service construit les destinations par concaténation directe de FidUrl et du chemin. Avec l’exemple ci-dessus, la destination de connexion est https://idp.example.net/saml/sso. Éviter les doubles slashs, les slashs manquants et les chemins déjà porteurs d’une chaîne de requête : le service ajoute lui-même ?SAMLRequest=.

FidSloPath et LogoutUrl concernent le parcours de déconnexion. Pour un raccordement comprenant ce parcours, les renseigner et le tester séparément de la connexion.

{
  "Saml": {
    "FidUrl": "https://idp.example.net",
    "FidSsoPath": "/saml/sso",
    "FidSloPath": "/saml/slo",
    "EntityId": "urn:example:immersive:recette",
    "LoginUrl": "https://rest.example.net/api/Saml/Login",
    "LogoutUrl": "https://rest.example.net/api/Saml/Logout"
  }
}

Les chemins /saml/sso et /saml/slo sont illustratifs. Les remplacer par les adresses fournies par l’administrateur de l’IdP. Reporter le préfixe public éventuel de RestFrontage dans LoginUrl et LogoutUrl.

Voir la présentation du fichier de Configuration du Rest Frontage

4.2 Déclarer le service auprès de l’IdP

1. Déclarer l’application ou le fournisseur de service correspondant à Immersive dans l’environnement cible.
2. Reporter la valeur EntityId à l’identique comme identifiant du fournisseur de service.
3. Déclarer LoginUrl comme URL ACS recevant la réponse par HTTP POST.
4. Pour la déconnexion fédérée, déclarer le retour LogoutUrl et vérifier le comportement attendu par l’IdP.
5. Configurer les attributs nécessaires au rapprochement du compte et prévoir un utilisateur pilote autorisé à accéder à cette application.
6. Vérifier les exigences de signature et de validation décrites dans le chapitre sur les limites avant toute ouverture en production.

Le service émet une AuthnRequest SAML 2.0, compressée avec Deflate puis encodée en Base64 et dans l’URL. Il indique un retour HTTP POST et une politique NameID de format transient. Lorsque forceAuthentication vaut true, il ajoute ForceAuthn à la demande.

Ces caractéristiques doivent être acceptées par l’IdP. Le code examiné ne fournit pas d’URL de métadonnées SAML ni d’option de certificat de signature dans SamlOptions. Il ne suffit donc pas d’inventer un paramètre MetadataUrl ou Certificate pour les activer.

4.3 Données attendues dans la réponse

Donnée	Utilisation
InResponseTo sur la réponse SAML	Repris comme identifiant de demande, pour retrouver le parcours lancé par le client.
SessionIndex dans AuthnStatement	Nécessaire à la reconnaissance de la réponse de connexion ; conservé pour la déconnexion.
Attribut cn	Premier attribut recherché pour le nom de compte externe.
Attribut http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name	Alternative utilisée si cn est absent.

La correspondance de compte repose sur un attribut SAML. La seule présence d’un NameID, d’une adresse électronique ou d’un attribut sub ne remplace pas cn ou l’attribut de nom attendu. Si cn est présent, il est prioritaire sur l’attribut alternatif.

Configurer une valeur simple et unique pour cet attribut. Le parseur retient le premier AttributeValue de chaque attribut ; les groupes et attributs multiples ne constituent pas un mécanisme d’attribution de droits.

4.4 Parcours de connexion

Un client comme le Beholder va suivre les étapes suivantes pour effectuer une connexion via le SSO SAML.

Le client prépare automatiquement deux valeurs pour démarrer la connexion. requestId est un identifiant généré à chaque nouvelle tentative : il permet de relier la demande SAML au retour du fournisseur d’identité.

Immersive Beholder génère un GUID et construit un identifiant contenant également l’adresse de retour. forceAuthentication est un choix du client : la valeur false autorise le fournisseur d’identité à réutiliser une session existante, selon sa politique, tandis que true demande une nouvelle authentification, même si une session existe déjà. Le Beholder utilise false par défaut. Ces deux valeurs sont gérées par le client : l’administrateur n’a rien à récupérer ni à saisir.

Les étapes sont les suivantes :

1. Le client crée un identifiant de demande propre à la tentative et appelle GET /api/Saml/GetSamlUrl avec requestId et forceAuthentication.
2. RestFrontage retourne une chaîne JSON contenant l’URL de connexion SAML ; cet appel ne redirige pas directement le navigateur.
3. Le client ouvre cette URL et l’utilisateur s’authentifie auprès de l’IdP.
4. Après l’authentification, le fournisseur d’identité fait transmettre la réponse SAML par le navigateur, en HTTP POST, à l’URL renseignée dans Saml:LoginUrl. Dans notre exemple précédent, cette valeur est https://rest.example.net/api/Saml/Login : elle désigne le point de réception fourni par RestFrontage pour lui laisser gérer automatiquement le traitement du retour SAML.
5. RestFrontage extrait les données attendues et tente d’enregistrer la demande et l’index de session sur le compte externe correspondant.
6. Le client chiffre l’identifiant de demande avec le contexte de sécurité Immersive et l’envoie à POST /api/Saml/Authenticate.
7. RestFrontage retrouve le compte, contrôle son état et retourne un AuthenticationToken contenant le jeton et l’utilisateur Immersive.

Pour les clients qui utilisent une redirection, le code sait interpréter un identifiant contenant une destination _redirect=, éventuellement encodé en hexadécimal. Les lanceurs présents dans RestFrontage construisent ce format. Utiliser le client prévu pour cette intégration plutôt que fabriquer une URL de retour arbitraire.

4.5 Déconnexion SAML

Un utilisateur Immersive authentifié peut demander GET /api/Saml/GetSamlLogoutUrl avec un requestId. Le service construit la demande de déconnexion à partir du compte externe et du SessionIndex conservé. L’IdP renvoie ensuite sa réponse sur /api/Saml/Logout, qui accepte GET et POST.

La fermeture de session chez l’IdP, l’effacement des données du client et l’invalidation des accès Immersive sont des opérations distinctes. Le retour Logout examiné affiche une page ou redirige ; il ne révoque pas explicitement les jetons Immersive dans cette méthode. Vérifier le comportement complet du client avant de considérer la déconnexion comme effective sur tous les accès.

5. Configurer le parcours OpenID

5.1 Différence avec un raccordement OIDC standard

OpenID Connect est une couche d’identité construite sur OAuth 2.0. Le standard définit notamment l’ID Token et le point de terminaison UserInfo. Voir la spécification OpenID Connect Core.

Le contrôleur OpenID de RestFrontage utilise un parcours particulier : le client a déjà obtenu un jeton d’accès externe et RestFrontage interroge les services tokeninfo et userinfo. Il ne configure pas, dans ce chemin, une découverte automatique .well-known/openid-configuration, un échange de code d’autorisation, une validation d’ID Token ou un renouvellement de jeton.

Ainsi, Authority, MetadataAddress, CallbackPath ou une URL /signin-oidc ne sont pas des paramètres de la section OpenID examinée. Les URL de redirection, scopes et modalités d’obtention du jeton sont à définir dans l’intégration entre l’application cliente et l’IdP.

5.2 Paramètres RestFrontage

Paramètre	Rôle effectif
OpenID:FidUrl	URL de base utilisée par RestFrontage pour appeler tokeninfo et userinfo. Prévoir un slash final si les services se trouvent sous un chemin.
OpenID:FidAppId	Identifiant comparé au client_id retourné par tokeninfo. À renseigner pour l’application autorisée.
OpenID:FidAppSecret	Option existante dans le modèle, mais non utilisée par les appels du contrôleur examiné. Elle n’active pas une authentification du client auprès de tokeninfo.

Exemple minimal des paramètres effectivement utilisés par le contrôleur :

{
  "OpenID": {
    "FidUrl": "https://idp.example.net/oauth2/",
    "FidAppId": "immersive-recette"
  }
}

Avec cette base, les appels visent https://idp.example.net/oauth2/tokeninfo et https://idp.example.net/oauth2/userinfo. Sans le slash final après oauth2, la résolution d’une URL relative peut supprimer ce segment et viser un autre emplacement.

Si une autre partie de votre intégration exige un secret, le fournir avec le mécanisme de secrets de l’hébergement. Dans ce contrôleur, renseigner FidAppSecret ne change pas le comportement des appels sortants. Une exigence de Basic authentication ou de client_secret sur tokeninfo nécessite une adaptation de l’intégration.

5.3 Contrat attendu de tokeninfo

RestFrontage effectue un appel GET relatif à FidUrl :

tokeninfo?access_token=JETON_ACCES_EXTERNE

Le contrôleur n’ajoute pas d’en-tête d’authentification à cet appel. Il attend une réponse JSON dont les champs exploités sont les suivants :

{
  "access_token": "JETON_ACCES_RETOURNE_PAR_IDP",
  "client_id": "immersive-recette",
  "realm": "/environnement-exemple"
}

La valeur client_id doit correspondre à FidAppId ; cette comparaison ignore la casse. Le jeton access_token renvoyé est ensuite utilisé pour appeler userinfo. Le champ realm sert de paramètre de cette deuxième requête.

Ces champs décrivent le contrat spécifique consommé par le code. Une réponse d’introspection qui ne contient que active, sub ou scope ne suffit pas à alimenter ce parcours. Le contrôleur ne vérifie pas explicitement un booléen active ni une durée expires_in.

5.4 Contrat attendu de userinfo

RestFrontage effectue ensuite cet appel, avec realm encodé dans l’URL :

GET /oauth2/userinfo?realm=%2Fenvironnement-exemple HTTP/1.1
Host: idp.example.net
Authorization: Bearer JETON_ACCES_RETOURNE_PAR_IDP

La réponse JSON doit notamment fournir le champ login utilisé pour retrouver le compte Immersive :

{
  "sub": "identifiant-externe-stable",
  "login": "agent.demo"
}

Dans ce parcours, la correspondance s’effectue sur login. Le contrôleur ne rapproche pas le compte à partir de sub, de l’adresse électronique ou d’un groupe. Le champ login est une exigence de cette intégration ; ce n’est pas un attribut garanti par tous les fournisseurs OIDC.

Le standard prévoit notamment la vérification de la cohérence de sub entre UserInfo et l’ID Token. Ce contrôle n’est pas réalisé dans le chemin examiné, qui ne valide pas l’ID Token. Voir UserInfo dans OpenID Connect Core.

5.5 Parcours de connexion

1. L’application cliente obtient un jeton d’accès externe auprès de l’IdP selon son propre parcours de connexion.
2. Elle peut appeler GET /api/OpenID/CheckToken avec le jeton en paramètre token pour vérifier les échanges tokeninfo et userinfo.
3. Elle récupère le contexte de sécurité Immersive, chiffre le jeton externe et l’envoie à POST /api/OpenID/Authenticate.
4. RestFrontage appelle tokeninfo, compare client_id, puis appelle userinfo.
5. RestFrontage rapproche login du compte Immersive, contrôle son état et retourne un AuthenticationToken.

Les deux routes OpenID exigent que l’en-tête Authorization puisse être analysé. Toutefois, les valeurs de cet en-tête ne sont pas exploitées par la méthode privée CheckToken : le jeton réellement traité provient du paramètre token ou du corps déchiffré, selon la route. L’en-tête reçu n’authentifie donc pas à lui seul l’application cliente dans ce chemin.

6. Configurer l’application cliente et les accès

6.1 Activer le bon parcours côté client

Les options serveur ne sélectionnent pas automatiquement le mode de connexion dans toutes les applications clientes. Le lanceur ou le client doit être configuré pour le protocole attendu et pour l’URL de RestFrontage.

La valeur de Login.Modes dans le fichier UserInfos.txt du Beholder doit contenir au minimum la valeur SAML pour permettre la connexion via le SAML et/ou OIDC pour OpenId.

Exemple : la valeur suivante permet un Beholder d'autoriser la connexion par défaut en login/password via les comptes Immersive mais aussi en SAML et OIDC :

"Login.Modes" : "SAML|OIDC|DEFAULT"

Les scripts Reader et Beholder examinés conservent l’identifiant SSO dans un cookie SSOToken pendant 30 secondes. Une connexion lente ou une étape multifacteur peut dépasser cette durée : si le retour SAML réussit mais que le lanceur recommence la connexion, contrôler ce point dans la version du client déployée.

6.2 Utiliser le contexte de sécurité Immersive

GET /api/Security/Context fournit un SecurityToken contenant la clé publique de chiffrement. Les routes Authenticate attendent ensuite une chaîne JSON chiffrée avec le mécanisme RSA compatible avec Immersive.

Route	Donnée à chiffrer
POST /api/Saml/Authenticate	Identifiant de demande reconnu après le retour SAML.
POST /api/OpenID/Authenticate	Jeton d’accès externe obtenu auprès de l’IdP.

La forme du corps HTTP est une chaîne JSON, comme dans cet exemple de structure non exécutable :

"DONNEE_CHIFFREE_PAR_LE_CLIENT_IMMERSIVE"

Ce corps n’est ni un objet contenant encryptedData, ni un identifiant en clair, ni le XML SAML. Utiliser l’implémentation de chiffrement compatible fournie au client. La clé publique ne remplace pas HTTPS.

6.3 Vérifier les droits après connexion

Après émission du jeton, vérifier l’identité Immersive effectivement retournée, les groupes du compte et ses droits sur les fonctions et objets nécessaires. Tester aussi une fonction qui doit rester interdite au compte pilote.

Les contrôleurs SAML et OpenID ne constituent pas une ouverture globale des droits. Le SSO établit l’identité ; les règles d’autorisation de la plateforme déterminent ensuite les accès.

7. Référence des routes

Méthode et route	Usage	Contexte attendu
GET /api/Security/Context	Fournit la clé publique Immersive.	Accessible avant authentification.
GET /api/Saml/GetSamlUrl	Renvoie l’URL IdP sous forme de chaîne JSON.	requestId et forceAuthentication ; accessible avant authentification.
POST /api/Saml/Login	Reçoit le retour SAML de connexion.	Réponse SAML transmise par le navigateur depuis l’IdP.
POST /api/Saml/Authenticate	Échange la demande SAML contre un jeton Immersive.	Identifiant chiffré dans une chaîne JSON.
GET /api/Saml/GetSamlLogoutUrl	Renvoie l’URL de déconnexion IdP.	Utilisateur Immersive authentifié et requestId.
GET ou POST /api/Saml/Logout	Reçoit le retour de déconnexion SAML.	SAMLResponse dans le format attendu par le contrôleur.
GET /api/OpenID/CheckToken	Exécute les appels externes de vérification.	token en paramètre de requête et en-tête Authorization analysable.
POST /api/OpenID/Authenticate	Échange le jeton externe contre un jeton Immersive.	Jeton externe chiffré dans une chaîne JSON et en-tête Authorization analysable.

Le contrôle direct du jeton OpenID le place dans l’URL, tout comme l’appel sortant à tokeninfo. Éviter d’enregistrer ces URL avec leurs paramètres dans les journaux d’accès ou dans un dossier de support non expurgé.

8. Recetter le raccordement

8.1 Vérifications communes

• Les URL correspondent à l’environnement cible et sont accessibles par les composants concernés.
• La configuration effective tient compte des éventuelles surcharges ; RestFrontage a été redémarré.
• Le compte pilote existe, possède un nom de compte externe unique et est activé, non expiré et non verrouillé.
• Une connexion complète retourne le bon utilisateur et un jeton Immersive.
• Le compte accède à une fonction autorisée et ne peut pas accéder à une fonction interdite.
• Un utilisateur externe sans compte Immersive correspondant n’obtient pas de jeton Immersive.
• Un compte Immersive désactivé, expiré ou verrouillé n’obtient pas de jeton.
• La déconnexion, la fermeture du client et la reconnexion ont été vérifiées séparément.

8.2 Vérifications SAML

• L’URL générée vise la bonne destination et la demande contient le bon EntityId et la bonne ACS.
• Le retour atteint /api/Saml/Login avec InResponseTo, SessionIndex et l’attribut de compte attendu.
• La connexion aboutit jusqu’à /api/Saml/Authenticate ; la page de retour seule n’est pas utilisée comme preuve.
• Une nouvelle tentative utilise un nouvel identifiant de demande ; le comportement de prévention du rejeu est contrôlé.
• Un parcours avec authentification multifacteur ou connexion lente aboutit aussi dans le client déployé.
• Les garanties de validation des assertions exposées au chapitre suivant sont effectivement présentes avant la mise en production.

8.3 Vérifications OpenID

• Depuis RestFrontage, FidUrl résout correctement tokeninfo et userinfo.
• tokeninfo fournit les champs requis et client_id correspond à FidAppId.
• userinfo fournit un login non vide correspondant au compte pilote.
• Un jeton expiré, révoqué ou émis pour une autre application est refusé sur le parcours complet.
• Les exigences d’authentification des services de l’IdP sont compatibles avec les appels réellement émis.
• La compatibilité de l’application cliente, de l’IdP et de cette version de RestFrontage est établie au-delà d’un seul retour 204.

Ces points constituent un plan de recette à exécuter. Ils ne décrivent pas des essais déjà réalisés sur un serveur ou un IdP.

9. Diagnostiquer les difficultés courantes

Symptôme	Vérification prioritaire
L’URL de connexion SAML est incorrecte	Vérifier la concaténation FidUrl + FidSsoPath et la configuration réellement chargée.
L’IdP refuse la demande SAML	Comparer EntityId, ACS, binding, politique NameID et exigences de signature avec la déclaration IdP.
Le retour de connexion affiche une erreur ou reste sans résultat utile	Vérifier le format du retour, InResponseTo, SessionIndex, cn ou l’attribut de nom alternatif. Un simple code HTTP réussi n’est pas une preuve de connexion complète.
La page de retour apparaît, mais Authenticate échoue	Vérifier le compte externe, l’identifiant de demande transmis, sa consommation éventuelle et le chiffrement du corps.
Le lanceur boucle après le retour SAML	Vérifier les cookies, la destination de retour et la durée de 30 secondes de SSOToken dans les lanceurs concernés.
Invalid request for given user en OpenID	Vérifier les deux appels IdP, client_id, login et le rattachement au compte Immersive.
CheckToken réussit, mais Authenticate échoue	Vérifier l’existence et l’état du compte Immersive ainsi que le chiffrement du jeton externe.
tokeninfo ou userinfo retourne 404	Vérifier FidUrl, son slash final et les chemins réels de l’IdP.
L’IdP exige un secret malgré FidAppSecret renseigné	Le contrôleur n’utilise pas ce secret pour ses appels ; faire adapter le raccordement.
Le compte est signalé comme verrouillé ou désactivé	Vérifier IsEnabled, ExpirationDate et LockoutUntilUtc dans le compte Immersive.
La connexion réussit, mais un accès métier est refusé	Vérifier les habilitations Immersive ; l’authentification externe n’accorde pas les droits métier.
La déconnexion IdP n’arrête pas tous les accès	Vérifier les données de session du client et le cycle de vie du jeton Immersive.

Les journaux peuvent notamment contenir « Demande Connexion SSO pour le CN extérieur », « Connexion SSO pour le CN extérieur », « Echec connexion SSO pour la requête » ou un événement de compte désactivé ou verrouillé. Corréler l’heure, le compte pilote et l’étape du parcours. Expurger jetons, réponses SAML et données personnelles avant de transmettre des traces.

10. Limites de la version examinée

10.1 Validation SAML à traiter avant une exposition en production

Le chemin examiné décode la réponse SAML et extrait ses attributs. Il ne montre pas de vérification cryptographique de signature, de chaîne de confiance IdP, d’audience, de destinataire, de statut SAML ou de conditions temporelles de l’assertion. Aucune option de certificat ou de métadonnées IdP n’est exposée par SamlOptions.

La présence de ces données dans une réponse n’en prouve donc pas l’authenticité. Les exigences de validation du profil SSO sont décrites dans les profils SAML 2.0 d’OASIS, section 4.1.

Le code conserve la demande et l’index de session dans le champ Code de l’utilisateur. Il tente d’effacer l’identifiant de demande lors de son échange contre un jeton. Cette consommation n’est pas une vérification de signature et ne suffit pas à démontrer une protection complète contre le rejeu ; le résultat de la méthode d’effacement n’est pas imposé comme condition de réussite par l’appelant.

Le parseur lit également le corps du retour SAML comme une chaîne et retire le préfixe SAMLResponse=. Il ne traite pas ce corps comme un ensemble complet de champs de formulaire. Recetter les réponses réelles de l’IdP, notamment lorsqu’elles comportent RelayState ou d’autres champs.

10.2 Compatibilité OpenID à confirmer

Le code contrôle client_id puis exploite login. Il ne met pas en œuvre une validation générique de jeton OIDC, ni une correspondance stable fondée sur le couple issuer et subject. Il ne vérifie pas explicitement active, les scopes ou l’expiration dans tokeninfo. Le refus d’un jeton révoqué ou expiré doit donc être confirmé dans le comportement réel des services IdP et dans la recette complète.

Le secret configuré n’est pas utilisé dans ce chemin. Les en-têtes d’autorisation reçus ne sont pas utilisés comme preuve d’identité du client appelant. Ces points limitent les contrats IdP compatibles et doivent être pris en compte si une authentification du client est exigée.

Ne pas annoncer une compatibilité validée avec Microsoft Entra ID, Keycloak, AD FS ou un autre fournisseur sur la seule présence des routes SAML et OpenID. Chaque fournisseur et chaque version nécessitent une vérification du contrat et du parcours complet.