Configuration de connexion Entra ID

Power Portals Pro connecte les utilisateurs chez Microsoft via le fournisseur standard AddMicrosoftAccount de ASP.NET Core, qui nécessite une inscription à l’application dans l’identifiant Microsoft Entra. L’enregistrement indique à Entra que votre portail est autorisé à demander des connexions, où il peut renvoyer les utilisateurs et avec quels identifiants il se prouvera. Cette page parcourt chaque propriété dont le portail dépend réellement.

Ce n’est pas l’application de connexion Dataverse

Deux enregistrements distincts sont impliqués dans un portail typique, et les confondre est une erreur courante en première exécution. L’application de connexion Dataverse est un principe de service qui lit et écrit les données sous le portail lui-même, et ses identifiants vont sous D365:ClientId / D365:ClientSecret. L’enregistrement décrit sur cette page est uniquement pour la connexion des utilisateurs, et ses identifiants vont sous Authentication:Microsoft:ClientId / ClientSecret. Utilisez deux enregistrements — ils nécessitent des propriétés différentes, et ils ont un rayon de blast très différent en cas de fuite.

1. Enregistrer la demande

Créez l’enregistrement dans le centre d’administration Microsoft Entra. Vous avez besoin au moins du rôle de développeur d’applications dans le locataire.

1. Connectez-vous au centre d’administration d’Entra, et si vous appartenez à plusieurs locataires, utilisez l’icône Paramètres pour passer au locataire qui devrait posséder l’enregistrement. Une inscription d’application ne peut pas être transférée entre locataires par la suite.
2. Parcourez Entrée ID > Inscriptions à l’application et sélectionnez Nouvelle inscription.
3. Saisissez un Nom, par Contoso Portal Sign-Inexemple . Les utilisateurs voient ce nom sur l’écran de consentement, alors faites-en quelque chose qu’ils reconnaîtront comme votre portail. Il pourra être modifié plus tard.
4. Dans la section Types de comptes supportés, choisissez l’audience qui correspond à votre portail — voir le tableau ci-dessous. C’est la propriété qui décide qui est autorisé à se connecter.
5. Sélectionnez Inscrire.
6. Sur la page Aperçu , copiez l’ID Application (client). Cette valeur devient Authentication:Microsoft:ClientId.

Choisir les types de comptes pris en charge

Ce réglage est la porte d’entrée du portail. Choisissez l’option la plus étroite qui couvre toujours tous ceux qui doivent se connecter :

Note

Le fournisseur Microsoft ASP.NET Core autorise toujours contre le point de terminaison multi-audience /common/ , donc le paramètre Types de comptes pris en charge — et non votre code d’application — est ce qui accepte ou rejette réellement un compte donné. Si un compte est refusé avec AADSTS50020, l’enregistrement est plus restreint que l’audience que vous visiez.

2. Ajouter l’URI de Redirection

Après une connexion réussie, Entra renvoie l’utilisateur vers votre portail via le chemin de rappel du fournisseur, qui est /signin-microsoft. Entra ne redirige que vers les adresses enregistrées à l’avance, donc chaque hôte sur lequel votre portail fonctionne doit avoir sa propre entrée.

1. Ouvre l’authentification sous Gérer, puis sélectionne Ajouter une plateforme.
2. Choisissez la plateforme Web — pas l’application Single-page. Le serveur portail effectue l’échange de jetons en utilisant le secret client, et cela reste vrai pour les hôtes Blazor WebAssembly et React, où la connexion est toujours gérée côté serveur.
3. Saisissez l’adresse de votre portail suivie de /signin-microsoft.
4. Répétez pour chaque environnement. L’URL de développement de launchSettings.json chaque hôte déployé et de chaque hôte déployé a tous besoin de son propre URI de redirection. Ils peuvent partager une seule inscription, ou vous pouvez garder une inscription séparée par environnement.

Important

L’URI de redirection doit correspondre exactement à ce que le portail envoie — schéma, hôte, port et chemin. https://localhost:7228/signin-microsoft et https://localhost:7228/signin-microsoft/ ne sont pas la même adresse, et deux ports différents ne sont pas non plus. Entra exige https pour tout sauf localhost.

Si le portail fonctionne derrière un reverse proxy, un load balancer ou une entrée de conteneur qui termine TLS, configurez ASP.NET middleware des en-têtes redirigés de Core. Sans cela, l’application croit que la requête est arrivée via HTTP simple et construit un http:// URI de redirection, qui ne correspondra pas à celui enregistré https:// .

3. Créer un secret client

Le secret est de savoir comment votre portail prouve qu’il s’agit bien de l’application enregistrée lorsqu’il échange le code d’autorisation contre un jeton.

1. Ouvrez Certificats & secrets sous Gérer et sélectionnez l’onglet Secrets du client.
2. Sélectionnez Nouveau secret client, donnez-lui une description qui nomme l’environnement (par exemple portal-production), puis choisissez une date d’expiration.
3. Copiez immédiatement la colonne Valeur — pas l’ID Secret. La valeur n’est affichée qu’une seule fois, et elle devient Authentication:Microsoft:ClientSecret.

Important

Les secrets clients expirent, et 24 mois est le maximum. Quand un client expire, chaque connexion Microsoft échoue AADSTS7000215 jusqu’à ce qu’elle soit remplacée, donc suivez la date d’expiration et faites une rotation avant celle-ci. Pour la production, les identifiants de certificat ou un identifiant d’identité fédéré évitent complètement le problème du secret d’expiration.

4. Vérification des permissions API

Un nouvel enregistrement est automatiquement accordé à Microsoft Graph User.Read (délégué), et c’est la seule autorisation dont le flux de connexion a besoin. Le fournisseur demande le https://graph.microsoft.com/user.read périmètre et lit le profil de l’utilisateur connecté depuis https://graph.microsoft.com/v1.0/me. Si quelqu’un a supprimé cette permission, rajoutez la permission sous les autorisations de l’API. L’octroi du consentement administrateur est optionnel dans la plupart des locataires de la main-d’œuvre mais évite d’afficher à chaque utilisateur une invite de consentement lors de la première connexion ; dans les locataires externes, c’est obligatoire.

Power Portals Pro lit ce qui suit à partir de ce profil lorsqu’il lie ou crée un utilisateur de portail :

Note

La mail propriété est vide pour les comptes qui n’ont pas de boîte Exchange Mailbox, auquel cas le fournisseur revient à userPrincipalName. Un UPN n’est pas toujours une adresse email routable — les comptes invités en particulier ont une forme de user_contoso.com#EXT#@yourtenant.onmicrosoft.com UPN — donc si votre portail met en relation les utilisateurs par email, attendez-vous à ce que ces comptes ne correspondent pas à un contact existant.

5. Stocker l’ID du client et le secret

Le portail lit les deux valeurs de configuration sous la Authentication:Microsoft section. Lors du développement, gardez-les dans des secrets utilisateur plutôt que appsettings.json de les garder pour qu’elles n’atteignent jamais le contrôle de version :

Ou depuis la ligne de commande, dans le répertoire du projet serveur :

Conseil

Dans les environnements hébergés, il faut fournir les mêmes clés que les variables d’environnement ou à partir d’un magasin secret. Les variables d’environnement utilisent un double soulignement au lieu du deux-points — Authentication__Microsoft__ClientId et Authentication__Microsoft__ClientSecret — car le séparateur des deux-points n’est pas portable entre plateformes.

6. Activer le fournisseur en Program.cs

Enregistrez le fournisseur en même temps que le reste de votre configuration d’authentification dans le projet Program.csserveur :

Le modèle de projet écrit cet appel pour vous lorsque vous sélectionnez les utilisateurs internes ou les deux audiences, ou lorsque vous optez pour la connexion Microsoft pour les utilisateurs externes. Si vous avez généré le projet sans cela, le même appel est envoyé commenté dans Program.cs — décommentez et fournissez les deux valeurs de configuration.

7. Connexion et vérification

Ouvrez le portail et ouvrez la page de connexion. Un bouton Microsoft apparaît désormais parmi les options de connexion. La première fois qu’un compte se connecte, le portail lie l’identité Microsoft à un utilisateur du portail — en faisant correspondre un contact existant par email lorsque possible, sinon il accompagne le visiteur dans l’inscription avec le nom et l’adresse e-mail de son profil préremplis.

Si le compte existe aussi en tant que Dataverse systemuser, la session peut s’exécuter en tant qu’utilisateur interne au lieu de se faire en tant que contact. Ce comportement ne nécessite aucune configuration supplémentaire dans l’enregistrement de l’application : Voir la connexion SystemUser

Dépannage

• AADSTS50011 — redirection de la correspondance d’URI. L’adresse envoyée par le portail n’est pas enregistrée. Comparez l’URI de l’erreur avec les entrées de la plateforme Web caractère pour caractère, incluant le port et l’absence d’une barre de suivi.
• AADSTS7000215 — secret client invalide. Habituellement, l’ID secret a été copié à la place de la valeur du secret, ou bien le secret a expiré. Créez un nouveau secret et mettez à jour la configuration.
• AADSTS50020 — le compte utilisateur du fournisseur d’identité n’existe pas dans le locataire. La connexion du compte est en dehors des types de comptes pris en charge par l’enregistrement. Élargissez les paramètres pour couvrir cette audience.
• Le aller-retour de connexion atterrit sur http://. Le portail est derrière un proxy terminant TLS sans middleware d’en-tête redirigé configuré, il génère donc des URI de redirection non sécurisées.
• Pas d’email sur le nouveau compte. Le compte Microsoft n’a pas de boîte aux lettres et il userPrincipalName a été utilisé à la place. Voir la note à l’étape 4.