OpenID Connect et connexion SAML

Outre Microsoft, Google et Facebook, un portail peut connecter les personnes via n’importe quel fournisseur d’identité OpenID Connect ou SAML 2.0 : Okta, Auth0, Microsoft Entra External ID, le locataire Entra propre d’un client ou partenaire, AD FS, Ping, Google Workspace. Chaque fournisseur que vous configurez est un bouton sur la page de connexion, et n’a besoin d’aucun code.

Une connexion via l’un de ces fournisseurs est appariée, liée ou inscrite en tant que contact exactement comme une connexion Microsoft ou Google. Les utilisateurs internes (utilisateurs du système) se connectent avec Microsoft — voir Configuration de connexion Entra ID.

Allume-le

Les projets créés à partir des modèles pour les utilisateurs externes ont déjà cette fonctionnalité dans Program.cs. Il lit chaque fournisseur configuré sous Authentication:OpenIdConnect et Authentication:Saml2, et n’en ajoute aucun jusqu’à ce qu’un soit configuré :

Le SAML provient du PowerPortalsPro.Identity.Saml2 package auquel ces projets font référence. Un projet créé avant cette fonctionnalité nécessite l’appel et l’ajout du package.

Adresses à enregistrer auprès du fournisseur

Chaque fournisseur a un nom — la clé de sa section de configuration, ContosoOkta dans les exemples ci-dessous — et les adresses vers lesquelles le fournisseur renvoie les personnes sont faites à partir de celui-ci en minuscules. Enregistrez-les exactement, une fois pour chaque hôte sur lequel le portail fonctionne.

Quoi	Adresse
URI de redirection OpenID Connect	`https://your-portal.example.com/signin-{name}`
Service consommateur d’assertion SAML (HTTP-POST)	`https://your-portal.example.com/saml2/{name}/acs`
ID d’entité SAML (audience)	`https://your-portal.example.com/saml2/{name}`
Les métadonnées SAML du portail	`https://your-portal.example.com/saml2/{name}/metadata`

Les adresses sont les mêmes dans toutes les langues. Une connexion commencée sur une page dans une autre langue — /es/… revient via l’adresse du site puis à la page sur laquelle elle a commencé, dans cette langue.

Fournisseurs OpenID Connect

Ajoutez une section pour chaque fournisseur sous Authentication:OpenIdConnect. Gardez le secret client dans les secrets utilisateur localement et dans Key Vault une fois déployé.

Cadre	Ce que c’est
`DisplayName`	Le nom sur le bouton de connexion. Par défaut, le nom du fournisseur est attribué.
`Authority`	L’émetteur du fournisseur — l’adresse sous laquelle il `/.well-known/openid-configuration` est. Obligatoire sauf `MetadataAddress` indication contraire.
`MetadataAddress`	L’adresse du document de découverte lui-même, pour un fournisseur qui le publie ailleurs.
`ClientId`, `ClientSecret`	L’identifiant client du portail et le secret chez le prestataire. Obligatoire.
`Scopes`	Des scopes à demander en plus `openid`de , `profile` et `email`, qui sont toujours demandés.
`CallbackPath`	Le chemin de l’URI de redirection, quand `/signin-{name}` ne fonctionne pas.
`TrustedEmailDomains`	Les domaines d’email pour lesquels ce fournisseur est fiable — voir Quelles adresses sont fiables ci-dessous. Vide par défaut. Dans un service d’application, écrivez-le séparé par des virgules.
`GetClaimsFromUserInfoEndpoint`	Savoir s’il faut lire le profil depuis le point d’accès d’information utilisateur du fournisseur ainsi que le jeton ID. Activé par défaut, puisque certains fournisseurs n’ont pas mis d’e-mail dans le jeton ID.

Le portail utilise le flux de code d’autorisation avec PKCE, se connecte via le cookie externe d’Identity et ne conserve aucun jeton. Il lit l’identifiant de la personne depuis sub, ainsi que son adresse et son nom depuis email, given_name et family_name.

Okta (OpenID Connect)

Créez une intégration d’application : OIDC - OpenID Connect, de type Application Web, avec l’autorisation de Code d’Autorisation .
Ajoutez l’URI de redirection du portail comme URI de redirection de connexion, assignez les personnes ou groupes qui peuvent se connecter, et copiez l’identifiant client et le secret.
L’autorité est l’émetteur de votre serveur d’autorisation, par exemple https://contoso.okta.com/oauth2/default:

Auth0

Créez une application du type Application Web Classique.
Ajoutez l’URI de redirection du portail aux URL de rappel autorisées, et copiez l’identifiant client et le secret.
L’autorité correspond au domaine de votre locataire, par https://contoso.us.auth0.com/exemple , ou à votre domaine personnalisé.

Microsoft Entra External ID

Dans le locataire externe, enregistrez une application avec l’URI de redirection du portail en tant qu’URI de redirection Web , et ajoutez un secret client.
Créez un flux utilisateur d’inscription et de connexion et ajoutez l’application à celui-ci.
L’autorité est https://<tenant subdomain>.ciamlogin.com/<tenant id>/v2.0. Lorsque le flux utilisateur vérifie chaque adresse avant la création d’un compte — l’email avec mot de passe et l’email à code d’accès à usage unique le font tous deux — il s’agit d’un fournisseur d’identité que vous gérez pour vos propres clients, et TrustedEmailDomains peut être *.

Le locataire Entra d’un client ou d’un partenaire

Pour une organisation dont les employés devraient se connecter avec leurs propres comptes professionnels, sans le bouton Microsoft multi-locataire :

Dans leur locataire, enregistrez une application locataire unique avec l’URI de redirection du portail en tant qu’URI de redirection Web , et ajoutez un secret client.
L’autorité est https://login.microsoftonline.com/<their tenant id>/v2.0.
Listez leurs domaines dans TrustedEmailDomains; une adresse ailleurs est d’abord confirmée par email. L’identifiant de leur locataire atteint la session, comme c’est le cas pour le bouton Microsoft. Les propres réclamations de vérification d’Entra (xms_edov, verified_primary_email) ne sont pas prises auprès d’un fournisseur : le locataire derrière elle administre les réclamations qu’il envoie.

Fournisseurs SAML 2.0

Ajoutez une section pour chaque fournisseur sous Authentication:Saml2. Les métadonnées du fournisseur donnent au portail son adresse de connexion et les certificats avec lesquels ses réponses sont signées ; il est lu chaque jour, de sorte qu’un certificat que le fournisseur renouvele est récupéré.

Cadre	Ce que c’est
`DisplayName`	Le nom sur le bouton de connexion. Par défaut, le nom du fournisseur est attribué.
`MetadataAddress`	L’adresse des métadonnées du fournisseur d’identité. Requise, et doit être `https`.
`IdentityProviderEntityId`	L’ID d’entité du fournisseur d’identité, qui doit fournir les réponses. Par défaut, c’est celui que ses métadonnées nomment.
`EntityId`	L’ID d’entité propre au portail. Par défaut, sur `https://{host}/saml2/{name}` l’hôte vers lequel la demande est venue ; régle-le lorsque le portail répond sur plus d’un hôte, afin qu’ils partagent une seule inscription chez le fournisseur.
`CallbackPath`, `MetadataPath`	Les chemins du service consommateur et des métadonnées de l’assertion, quand `/saml2/{name}/acs` et `/saml2/{name}/metadata` ne feront pas l’affaire.
`TrustedEmailDomains`	Les domaines d’email pour lesquels ce fournisseur est fiable — voir Quelles adresses sont fiables ci-dessous. Vide par défaut. Dans un service d’application, écrivez-le séparé par des virgules.
`AllowIdentityProviderInitiated`	Accepte les connexions que le fournisseur lance — quelqu’un ouvrant le portail depuis une tuile sur le tableau de bord de son fournisseur. Désactivé par défaut. Ils accèdent à la page de connexion externe du portail, puis à une page locale nommée par RelayState (`/orders` ou `ReturnUrl=/orders`). Chaque réponse est acceptée une fois par serveur.
`RequireHttpsMetadata`	Ou `MetadataAddress` doit être `https`. Activé par défaut ; désactivez-le uniquement pour essayer un fournisseur qui tourne sur votre propre machine.

Les réponses doivent être signées par un certificat dans les métadonnées du fournisseur, émis par son identifiant d’entité, pour l’identifiant d’entité du portail, envoyé au service consommateur d’assertion, et en réponse à la demande faite par le même navigateur. Le NameID identifie le compte, il doit donc être persistant ou l’adresse e-mail ; un certificat transitoire est refusé. L’adresse et le nom sont lus à partir des attributs que les fournisseurs utilisent couramment : email, mail, emailaddress et les noms de revendication WS-Federation, et givenName , ou firstName surname ou lastName.

Microsoft Entra ID (application d’entreprise)

Créez une application entreprise, intégrez toute autre application que vous ne trouvez pas dans la galerie, et choisissez l’accès unique SAML .
Définir l’identifiant (ID d’entité) sur l’ID d’entité du portail et l’URL de réponse sur son service consommateur d’assertion.
Copiez l’URL des métadonnées de la fédération d’applications dans MetadataAddress, et assignez les utilisateurs ou groupes qui peuvent se connecter.

Okta (SAML)

Créez une intégration d’application de type SAML 2.0.
Définir l’URL de connexion unique au service consommateur d’assertion et l’URI d’audience (ID d’entité SP) à l’ID d’entité du portail ; choisir un format d’ID de nom Persistent ou d’adresse email , et ajouter emailles instructions , firstName et lastName attribut.
Copiez l’URL des métadonnées de l’application dans MetadataAddress.

AD FS

Ajoutez un trust de la partie de confiance, en important les métadonnées du portail depuis son adresse.
Ajoutez des règles d’émission de réclamation qui envoient l’adresse e-mail, le prénom et le nom de famille, ainsi qu’un identifiant de nom persistant.
MetadataAddress est https://<your AD FS host>/FederationMetadata/2007-06/FederationMetadata.xml.

Requêtes signées et assertions chiffrées

La plupart des fournisseurs n’ont besoin de l’un ou de l’autre. Pour un fournisseur qui nécessite des demandes d’authentification signées ou chiffre ses assertions, ajoutez le fournisseur en code avec les certificats ; les deux sont publiés dans les métadonnées du portail pour que le fournisseur puisse les importer.

Quelles adresses sont fiables

Une connexion dont l’adresse est fiable va directement dans le contact qui la détient, et un nouveau compte commence avec cette adresse confirmée. Toute autre adresse est confirmée par email en premier, une seule fois ; ensuite, c’est le lien entre la connexion et le contact qui la trouve.

Un fournisseur n’est fiable que pour les domaines listés dans son TrustedEmailDomains, apparié exactement — contoso.com ne couvre mail.contoso.compas . Listez les domaines dont les boîtes aux lettres sont contrôlées par l’organisation derrière le fournisseur.
Un fournisseur qui affirme ne pas avoir vérifié une adresse (OpenID email_verified Connect est le cas false) n’est pas fiable pour cela, quoi que la liste indique.
Rien d’autre ne l’est : un fournisseur ne peut pas garantir une adresse en envoyant les propres réclamations du portail, et un système de connexion ajouté d’une autre manière ne garantit jamais une adresse.

Important
* Fait confiance à chaque adresse que le fournisseur revendique. Utilisez-le uniquement pour un fournisseur d’identité que vous gérez pour vos propres utilisateurs et qui vérifie les adresses avant de les asserter. Ne l’utilisez jamais pour un fournisseur administré par un client ou un partenaire : toute personne qui l’administre peut créer un compte avec n’importe quelle adresse, y compris celle appartenant à un contact d’une autre organisation, et se connecterait sous ce nom.

Boutons de connexion

Chaque fournisseur est un bouton sur la page de connexion, intitulé avec son nom d’affichage. Quatre autres paramètres dans la section d’un fournisseur modifient l’apparence de son bouton et son emplacement :

Cadre	Ce que c’est
`Icon`	Un petit logo affiché avant le nom dans le bouton standard — par exemple le logo propre d’un client sur sa connexion.
`ButtonImage`	Une image affichée à la place du bouton standard : le bouton « Connexion avec ... » d’un fournisseur lui-même. bouton.
`ButtonImageDark`	La même image pour le thème sombre. Sans elle, `ButtonImage` est utilisée dans les deux.
`Order`	Là où se trouve le bouton : le plus bas vient en premier, et les boutons avec la même commande conservent l’ordre dans lequel leurs prestataires ont été ajoutés. 0 par défaut.

Une image est un chemin depuis la racine du site — un fichier dans le portail wwwroot, comme /images/contoso-logo.svg — ou une https adresse. Un chemin est servi à partir de la racine du site sur chaque page, dans chaque langue. Tout autre élément arrête le portail au démarrage, en nommant le paramètre.

Le bouton de tout autre fournisseur, y compris celui de Microsoft et de Google, est modifié dans le code :

Microsoft, Google et Facebook affichent leurs propres boutons « Connectez-vous avec ... » en versions claires et sombres, sauf si vous en configuriez un pour eux.

Dépannage

Le fournisseur refuse l’URI de redirection ou l’URL de réponse. Il doit correspondre exactement — schéma, hôte, port et chemin. Registre https://{host}/signin-{name}, ou les adresses SAML, pour chaque hôte sur lequel le portail fonctionne.
Le portail ne démarre pas, en nommant un Authentication:OpenIdConnect paramètre OR Authentication:Saml2 . Un fournisseur configuré manque d’une valeur requise ou en a une déformée. Les serveurs check_setup MCP listent chaque fournisseur, ce qui lui manque et les adresses à enregistrer.
Une connexion SAML échoue avec « Signature invalide ». La réponse était signée par un certificat que le portail n’a pas vu — généralement parce que le fournisseur a relégué son certificat. Le portail lit à nouveau les métadonnées dans la journée ; redémarrez-le pour les lire maintenant.
« Validation d’audience échouée » ou « Émetteur invalide ». L’identifiant d’entité enregistré chez le fournisseur n’est pas celui utilisé par le portail — configuré EntityId pour correspondre — ou la réponse provient d’une autre entité que IdentityProviderEntityId des noms.
Une connexion SAML échoue car le NameID est transitoire. Demandez au fournisseur d’envoyer un NameID persistant, ou l’adresse e-mail.
Ouvrir le portail depuis la tuile du tableau de bord d’un fournisseur revient à la page de connexion. Le portail n’a pas demandé cette connexion. Défini AllowIdentityProviderInitiated pour ce fournisseur.
Chaque première connexion envoie un e-mail de confirmation. Le domaine de l’adresse n’est pas dans celui du TrustedEmailDomainsfournisseur. C’est la valeur sûre par défaut ; une fois l’adresse confirmée, les connexions ultérieures sont directement intégrées.