Planifier l’authentification d’application dans SharePoint Server
S’APPLIQUE À :
2013 2016 2019 Édition d’abonnement 
SharePoint dans Microsoft 365
L'authentification d'application correspond à la validation de l'identité d'une application pour SharePoint externe et à l'autorisation de l'application et d'un utilisateur associé quand l'application demande un accès à une ressource SharePoint sécurisée. L'authentification d'application se produit quand un composant externe d'une application SharePoint Store ou d'une application du Catalogue d'applications, telle qu'un serveur web situé sur un intranet ou sur Internet, essaie d'accéder à une ressource SharePoint sécurisée. Par exemple, une application pour SharePoint qui comprend un composant s'exécutant dans Microsoft Azure est une application externe. L'authentification d'application permet de nouvelles fonctionnalités et de nouveaux scénarios qui peuvent être obtenus en autorisant les applications à inclure des données de ressources SharePoint dans les résultats que l'application traite et présente aux utilisateurs.
Pour fournir les ressources demandées à partir d'une application pour SharePoint, le serveur qui exécute SharePoint Server doit :
Vérifier que l’application à l’origine de la demande est approuvée.
Pour authentifier l’application à l’origine de la demande, vous devez configurer le serveur qui exécute SharePoint Server afin qu’il approuve l’application qui envoie la demande. Il s'agit d'une relation d'approbation à sens unique.
Vérifier que le type d’accès demandé par l’application est autorisé.
Pour autoriser l’accès, SharePoint Server se base sur les autorisations d’application, qui ont été définies dans le fichier manifeste de l’application au moment de son installation, et les autorisations associées à l’utilisateur au nom duquel l’application agit. SharePoint Server s’appuie également sur les autorisations qui ont été accordées au SPAppPrincipal lorsque l’approbation a été établie à l’aide de l’applet de commande PowerShell Set-SPAppPrincipalPermission .
Notez que l’authentification d’application dans SharePoint Server est distincte de l’authentification utilisateur et qu’elle n’est pas utilisée comme protocole d’authentification de connexion par les utilisateurs SharePoint. L'authentification d'application utilise le protocole Open Authorization (OAuth) 2.0 et ne vient pas s'ajouter à l'ensemble de protocoles de connexion et d'authentification utilisateur, tels que WS-Federation. Il n'existe pas de nouveaux protocoles d'authentification utilisateur dans SharePoint Server. L’authentification d’application et OAuth ne figurent pas dans la liste des fournisseurs d’identité.
Introduction
La planification de l’authentification d’application se compose des tâches suivantes :
Identifier l’ensemble de relations d’approbation à configurer sur la batterie qui exécute SharePoint Server correspondant aux applications externes qui demanderont des ressources SharePoint.
Fournir l’accès entrant à partir d’applications externes hébergées sur Internet.
Importante
Les applications web qui comprennent des points de terminaison d'authentification d'application (pour les demandes entrantes par des apps pour SharePoint) doivent être configurées pour utiliser SSL (Secure Sockets Layer). Vous pouvez configurer OAuth dans SharePoint Server pour que SSL ne soit pas requis. Cependant, nous vous conseillons de le faire uniquement dans un but d’évaluation, afin de faciliter la configuration ou de créer un environnement de développement d’applications.
Notes
Vous n'avez besoin de planifier l'authentification d'application sur une batterie SharePoint que si vous utilisez une ou plusieurs apps pour SharePoint externes qui nécessitent ses ressources.
Identifier l’ensemble des relations d’approbation
Vous devez configurer la batterie SharePoint pour approuver les jetons d’accès qui correspondent aux demandes de ressources envoyées par les types d’applications externes suivants :
Les applications hébergées par un fournisseur s'exécutent sur leurs propres serveurs sur Internet ou un intranet, elles sont inscrites auprès d'Microsoft Azure et utilisent ACS pour obtenir le jeton d'accès.
Pour les applications hébergées par un fournisseur, vous devez configurer la batterie SharePoint pour qu’elle approuve l’instance ACS de l’application hébergée par un fournisseur.
Applications à haut niveau de fiabilité exécutées sur des serveurs autonomes sur votre intranet et qui utilisent un certificat de signature pour signer numériquement les jetons d’accès générés par l’application.
Les applications à haut niveau de fiabilité utilisent le protocole S2S pour demander des ressources au nom d’un utilisateur. Pour les applications à haut niveau de fiabilité, configurez la batterie SharePoint avec le point de terminaison de métadonnées JSON (JavaScript Object Notation) du serveur qui héberge l’application. Vous pouvez également configurer manuellement l’approbation. Pour plus d’informations, voir Configurer l’authentification des applications dans SharePoint Server.
Pour plus d’informations sur les applications à haut niveau de fiabilité, reportez-vous à la procédure pour la création d’applications à haut niveau de fiabilité pour SharePoint 2013 à l’aide du protocole S2S.
Choisir les méthodes d’authentification des utilisateurs pour les applications locales
Une application locale est soit une application hébergée par un fournisseur sur un serveur local, soit une application hébergée par SharePoint. Le tableau 1 répertorie les différentes méthodes d’authentification utilisateur de SharePoint Server et indique si ces méthodes peuvent être utilisées pour des applications locales SharePoint Server.
Tableau 1. Méthodes d’authentification des utilisateurs et prise en charge par les applications locales
| Méthode d'authentification | Prise en charge par les applications SharePoint hébergéees | Prise en charge par des applications fournisseur hébergées |
|---|---|---|
| NTLM |
Oui |
Oui |
| Kerberos |
Oui, mais uniquement lorsqu’elle est configurée pour utiliser la méthode NTLM en tant que méthode d’authentification de secours. L’utilisation de la méthode Kerberos seule n’est pas prise en charge. |
Oui |
| De base |
Oui |
Oui |
| Anonyme |
Oui |
Oui |
| Authentification basée sur les formulaires à l’aide du fournisseur ASP.NET par défaut |
Oui |
Oui |
| Authentification basée sur les formulaires avec protocole LDAP (Lightweight Directory Access Protocol) |
Oui |
Oui |
| Authentification de Security Assertion Markup Language (SAML) |
Oui, si le fournisseur d’identité prend en charge l’inscription de l’URL (Uniform Resource Locator) de retour par caractère générique et respecte le paramètre wreply . . Pour configurer SharePoint Server afin qu’il utilise le paramètre wreply, utilisez les commandes suivantes dans une invite de commande Microsoft PowerShell : $p = Get-SPTrustedIdentityTokenIssuer$p.UseWReplyParameter = $true$p.Update()
> [! REMARQUE]> Active Directory Federation Services (AD FS) version 2.0 ne prend pas en charge les caractères génériques pour l’inscription d’URL de retour. |
Oui |
Pour plus d’informations sur les méthodes d’authentification utilisateur dans SharePoint Server, reportez-vous à l’article Planifier les méthodes d’authentification utilisateur dans SharePoint Server.
Fournir l’accès entrant à partir d’applications externes hébergées sur Internet
Si des applications externes hébergées par un fournisseur sont situées sur Internet, vous devez configurer un proxy web inverse pour effectuer l’authentification de l’application et demander des ressources de batteries SharePoint sur l’intranet. Un proxy web inverse configuré à l’extrémité de votre réseau doit autoriser les connexions entrantes HTTP sur SSL (HTTPS) des applications vers vos batteries SharePoint. Pour cela, vous identifiez généralement les URL HTTPS que les applications externes utiliseront et configurez le proxy inverse pour publier ces URL et fournir la sécurité appropriée.
Répondre aux préoccupations liées à l’application de service de profil utilisateur
Les applications à haut niveau de fiabilité génèrent leurs propres jetons d’accès, qui incluent une assertion de l’identité de l’utilisateur au nom duquel elles agissent. Le serveur qui exécute SharePoint Server et traite la demande de ressource entrante doit être en mesure de résoudre la demande à un utilisateur SharePoint spécifique, un processus appelé réhydratation de l’identité de l’utilisateur. Notez que cela diffère de l’authentification d’application pour les applications hébergées par un fournisseur, dans laquelle l’utilisateur est identifié, mais pas déclaré.
Dans le cadre de ce processus, un serveur qui exécute SharePoint Server extrait les revendications du jeton d'accès entrant et identifie l'utilisateur SharePoint correspondant. Par défaut, SharePoint Server utilise l'application de service Profil utilisateur comme outil de résolution d'identité.
Les attributs d’utilisateur clés pour la réactivation de l’identité de l’utilisateur sont les suivants :
Identificateur de sécurité Windows (SID)
Nom d’utilisateur principal (UPN) pour les services de domaine Active Directory (AD DS)
Adresse du service SMTP (Simple Mail Transfer Protocol)
Adresse du service SIP (Session Initiation Protocol)
C’est pourquoi, l’application doit inclure au moins l’un de ces attributs utilisateur et que cet attribut doit être à jour dans les profils utilisateur. Nous vous recommandons d’effectuer régulièrement une synchronisation entre les magasins d’identités et l’application de service de profil utilisateur.
De plus, SharePoint Server ne s’attend à trouver qu’une entrée dans l’application de service Profil utilisateur pour une requête de recherche donnée qui est basée sur ces quatre attributs. Sinon, il retourne une condition d'erreur indiquant que plusieurs profils utilisateur ont été trouvés. Ainsi, vous devez régulièrement supprimer les profils utilisateur obsolètes de l’application de service Profil utilisateur pour éviter les profils utilisateur multiples.
Si un profil utilisateur existe pour un utilisateur et que les appartenances à un groupe appropriées ne sont pas synchronisées, l’accès risque d’être refusé quand l’utilisateur est supposé se voir accorder l’accès à une ressource donnée. Ainsi, assurez-vous que les appartenances à un groupe sont synchronisées avec l’application de service de profil utilisateur.