Connexion SystemUser

Power Portals Pro reconnaît les enregistrements Dataverse systemuser connectés comme utilisateurs du portail — aux côtés des utilisateurs par défaut contactsoutenus. Aucune configuration n’est requise : lorsqu’un utilisateur se connecte via l’authentification Microsoft, le portail cherche d’abord une correspondance systemuser; si une configuration existe, la session s’exécute sous le nom de l’utilisateur système et Dataverse impose la sécurité par usurpation d’identité. Si aucun utilisateur système correspondant n’est trouvé, la connexion revient au chemin de contact. Le même portail peut servir à la fois le personnel interne agréé Dataverse et les contacts clients externes.

Quand cela compte

Le flux soutenu par l’utilisateur du système est utile lorsque :

Le portail sert le personnel — employés, agents de support, partenaires titulaires de licences Dataverse — déjà provisionnés en tant qu’utilisateurs du système.
Vous voulez que les rôles de sécurité Dataverse soient la source unique de vérité sur ce que ces utilisateurs peuvent voir et faire.
Vous ne voulez pas dupliquer l’identité en maintenant un enregistrement parallèle contact pour chaque utilisateur du personnel.

Authentification Microsoft uniquement
Seul le fournisseur externe Microsoft / Entra ID peut résoudre en un utilisateur système ; les utilisateurs sont appariés contre systemuser.azureactivedirectoryobjectid, et tout utilisateur système avec isdisabled = true est bloqué. Nom d’utilisateur/mot de passe local et d’autres fournisseurs externes (Google, etc.) se connectent toujours en tant que contact.

Comment ça fonctionne

Lors d’une connexion Microsoft, le portail :

Recherche l’ID d’objet Azure AD authentifié par rapport systemuser.azureactivedirectoryobjectidà . Si un enregistrement actif correspond, la session est liée à cet utilisateur système.
Sinon, il revient au flux par contact (correspondant à la connexion externe via adx_externalidentity).
Pour les sessions systemuser, ServiceClient.CallerId est défini pour systemuserid que chaque appel Dataverse s’exécute en tant qu’utilisateur connecté — avec leurs rôles de sécurité, leur portée d’unité métier et leur accès au niveau des lignes. Les instances ITablePermissionHandler côté portail ITableRecordPermissionHandler / les instances sont contournées pour la demande.
Les grilles, formulaires et boutons reflètent les véritables privilèges Dataverse de l’utilisateur — calculés à partir de RetrieveUserPrivilegesRequest chaque utilisateur et mis en cache. Les sessions de contact continuent de circuler via les gestionnaires enregistrés comme auparavant.

Modèle de sécurité

Pour les sessions soutenues par l’utilisateur système, car CallerId l’usurpation d’identité délègue l’application à Dataverse :

La sécurité au niveau des enregistrements et des colonnes provient du ou des rôles de sécurité Dataverse de l’utilisateur connecté — et non du code du portail.
La sécurité au niveau du terrain, la propriété hiérarchique et la portée des unités métier s’appliquent toutes automatiquement.
Les gestionnaires d’autorisations côté portail (ITablePermissionHandler / ITableRecordPermissionHandler) sont contournés pour la demande. Ils continuent à fonctionner comme d’habitude pour les sessions soutenues par contact dans le même portail.
Les rôles de sécurité Dataverse de l’utilisateur sont projetés sur le principal sous forme ClaimTypes.Role de revendications, de sorte que les attributs existants [Authorize(Roles = "…")] et User.IsInRole(...) les vérifications fonctionnent contre eux sans avoir à faire un aller-retour supplémentaire sur Dataverse par requête. Les réclamations se rafraîchissent lors de la validation principale, donc les attributions de rôles effectuées dans Dataverse sont détectées dans l’intervalle de tampon de sécurité (~10 minutes) sans forcer une reconnexion.

Admins : tests en tant que contact

Les administrateurs du portail doivent généralement vérifier l’expérience côté contact — la page d’accueil s’affiche-t-elle correctement pour un client connecté ? Ce cas masque-t-il correctement ce bouton de la barre d’outils ? — sans perdre leur capacité à effectuer des actions administratives. Power Portals Pro prend cela en charge directement : un administrateur peut garder une connexion Microsoft liée à la fois à systemuser un (compte interne) et à contact un (enregistrement de test, ou son propre compte côté client), et passer d’un compte à l’autre sans se déconnecter.

Choisissez lors de la connexion. Lorsqu’une connexion Microsoft se résout à plus d’une identité, la page post-rappel affiche un sélectionneur listant chaque candidat (type + nom d’affichage + email). En choisissant un compte l’utilisateur avec cette identité pour le reste de la session.
Tu te souvenais de la pièche. Le sélectionneur écrit un petit cookie par clé fournisseur, donc les connexions suivantes sautent l’invite et passent directement à la dernière identité choisie. Le pick-up mémorisé se met à jour chaque fois que l’utilisateur bascule en session, donc la prochaine connexion ambiguë respecte la nouvelle préférence.
Interrupteur en session. Lorsque l’utilisateur connecté a une identité sœur, une entrée Switch to Contact / Switch to SystemUser apparaît dans le menu du profil. Il s’affiche sur /api/auth/switch-identity, qui réédite le cookie d’authentification pour l’identité alternative — aucun aller-retour OAuth neuf n’est nécessaire. Le point de terminaison lit l’identifiant alternatif du principal (jamais depuis le corps de la demande), donc un clic altéré ne peut pas connecter l’utilisateur en tant qu’autre personne.

Publics mixtes : conçussez vos données en conséquence
Un portail unique peut servir à la fois les utilisateurs système et les utilisateurs de contact dans le même déploiement. Si vos personnalisations incluent des filtres FetchXML qui adx_contactid == currentUserId permettent de définir les lignes (un schéma courant dans les portails à contact unique), ces filtres n’auront pas de sens lorsque l’utilisateur connecté est un utilisateur système. Faites une ramification de votre code de personnalisation sur le type utilisateur afin que chaque audience voie les données qui lui sont appropriées.

Caches de privilèges

La carte de métadonnées de privilèges à l’échelle de l’environnement est chargée une fois au démarrage de l’application et mise en cache indéfiniment ; Redémarrer l’application (ou appel IPrivilegeMetadataCache.InvalidateAsync) pour détecter de nouvelles tables ou modifier le schéma de privilèges. Les privilèges effectifs de chaque utilisateur système connecté sont mis en cache pendant 24 heures et peuvent être évincés avec IUserPrivilegeCache.InvalidateAsync(userId).