Partager via

Création de compléments SharePoint qui utilisent l’autorisation de confiance basse

  • Article

Les composants distants d’un complément SharePoint (ou d’une application externe) peuvent obtenir une autorisation d’accès aux ressources de SharePoint en transmettant un jeton d’accès à SharePoint avec chaque demande HTTP. Les composants distants obtiennent ce jeton d’accès dans un compte Microsoft Azure Access Control Service (ACS) associé avec le client Office 365 du client. Azure ACS joue un rôle de serveur d’autorisation dans une transaction OAuth 2.0, appelée flux, où SharePoint est le serveur de ressources et les composants distants sont le client. Pour connaître les spécifications de protocole connexes, reportez-vous à la rubrique Protocole d’autorisation web (oauth).

Importante

Le contrôle d’accès Azure (ACS), un service d’Azure Active Directory (Azure AD), ne sera plus disponible à partir du 7 novembre 2018. Ce retrait n?a aucune incidence sur le mod?le de compl?ments SharePoint, qui utilise lehttps://accounts.accesscontrol.windows.net nom d?h?te (qui n?est pas affect? par ce retrait). Pour plus d’informations, voir Conséquences du retrait du contrôle d’accès Azure pour les compléments SharePoint.

Les compléments SharePoint hébergés par un fournisseur qui utilisent le système d’autorisation à faible niveau de confiance peuvent être vendus dans l’Office Store et installés sur Microsoft SharePoint Online ou une batterie de serveurs SharePoint locale qui a été configurée pour utiliser le client Office 365 du client pour établir la relation d’approbation avec Azure ACS. Le client doit disposer d’un client Office 365 pour installer des compléments SharePoint qui utilisent le système à faible niveau de confiance. Toutefois, le client n’a pas besoin d’utiliser le client à d’autres fins. Pour obtenir des instructions sur la liaison d’une batterie de serveurs locale à un client Office 365, reportez-vous à la rubrique Utiliser un site SharePoint Office 365 pour autoriser des compléments hébergés par un fournisseur sur un site SharePoint local.

Inscription auprès d’Azure ACS

Pour utiliser le système à faible niveau de confiance, le complément SharePoint doit tout d’abord être inscrit auprès d’Azure ACS et du service de gestion des applications de la batterie de serveurs SharePoint ou du client SharePoint Online. (Il est appelé « service de gestion », car les compléments SharePoint étaient initialement appelés « applications pour SharePoint ».)

Pour les compléments vendus par l’Office Store, l’inscription à ACS est effectuée dans le service Mon tableau de bord vendeur et l’inscription au service est effectuée lorsque le complément est installé.

Pour les compléments distribués dans le catalogue de compléments de l’organisation, l’inscription à ACS et au service est effectuée sur la page _Layouts\15\AppRegNew.aspx de toute location ou batterie de serveurs SharePoint où le complément doit être installé. Les applications externes, autres que SharePoint, qui accèdent à SharePoint doivent également être inscrites. Cette catégorie inclut les compléments Office, les applications Windows Store et les applications pour appareil telles que celles pour les smartphones.

Remarque

L’inscription requiert que l’application ait un domaine Internet. Tout domaine existant peut être utilisé à cette fin, mais vous ne pouvez pas être certain à 100 % qu’un domaine que vous ne possédez pas existera toujours. C’est pourquoi une application web doit faire partie d’une application de périphérique native, même si le composant d’application web sert uniquement à permettre l’inscription. Pour un exemple de code avancé conçu de cette façon, reportez-vous à la rubrique Fournir des sites en lots avec le modèle du complément.

Pour plus d’informations sur l’inscription, reportez-vous à la rubrique Enregistrer des compléments SharePoint 2013.

Expiration de la clé secrète d’un complément

La clé secrète d’un complément doit être remplacée tous les 12 mois. Pour plus de détails, reportez-vous à la rubrique Remplacement d’une clé secrète client arrivant à expiration dans un complément pour SharePoint.

Stratégies d’autorisation

Un complément SharePoint peut être conçu pour utiliser l’une des trois stratégies d’autorisation suivantes :

  • Stratégie d’utilisateur uniquement. Lorsque la stratégie d’utilisateur uniquement est utilisée, SharePoint vérifie uniquement les autorisations de l’utilisateur. SharePoint utilise cette stratégie lorsque l’utilisateur accède aux ressources directement sans utiliser de complément, par exemple lorsqu’un utilisateur ouvre pour la première fois la page d’accueil d’un site SharePoint ou accède pour la première fois aux API SharePoint à partir de PowerShell.

  • Stratégie complément uniquement Un complément qui utilise cette stratégie peut effectuer toutes les actions qu’il est autorisé à faire, même si l’utilisateur n’est pas autorisé à effectuer l’action. Le développeur doit demander que cette stratégie soit utilisée dans le manifeste de complément du complément. La demande doit être approuvée par l’utilisateur qui installe le complément. Cette stratégie est uniquement autorisée pour les compléments SharePoint hébergés par un fournisseur.

  • Stratégie utilisateur+complément Les compléments qui utilisent cette stratégie peuvent uniquement effectuer des actions sur lesquelles le complément et l’utilisateur bénéficient d’autorisations. Il s’agit de la stratégie utilisée par défaut, sauf si le développeur prend des mesures spécifiques pour en utiliser une autre.

Pour plus d’informations sur les stratégies d’autorisation, reportez-vous à la rubrique Types de stratégie d’autorisation des compléments dans SharePoint.

Deux flux de runtime OAuth

À chaque exécution d’un complément SharePoint hébergé sur le cloud ou d’une application externe qui accède à SharePoint, un flux, ou une série d’interactions entre le complément, SharePoint, ACS, et parfois l’utilisateur, se produit. Le flux a pour résultat final que SharePoint reçoit un jeton d’accès inclus avec chaque demande créer, lire, mettre à jour et supprimer (CRUD) que l’application envoie à SharePoint.

Il existe deux flux OAuth principaux utilisés par SharePoint. L’une concerne les compléments SharePoint hébergés dans le cloud. L’autre, appelée « à la volée », concerne les applications sur d’autres plateformes qui accèdent aux données SharePoint.

  • Flux de jeton de contexte Le composant distant du complément SharePoint utilise le modèle objet client SharePoint (CSOM) ou des points de terminaison REST pour effectuer des appels vers SharePoint. SharePoint demande un jeton de contexte à ACS afin de l’envoyer au serveur distant. Le serveur distant utilise le jeton de contexte pour demander un jeton d’accès à ACS. Le serveur distant utilise ensuite le jeton d’accès pour répondre à SharePoint.

    Pour plus d’informations sur ce flux, reportez-vous à la rubrique Flux OAuth avec jetons de contexte pour les compléments SharePoint.

  • Flux de code d’authentification. Un complément SharePoint reçoit les autorisations dont il a besoin sur les ressources SharePoint lors de son installation. En revanche, les applications qui ne sont pas installées sur SharePoint doivent demander des autorisations « à la volée », autrement dit à chaque fois qu’elles sont exécutées. Il n’existe aucun jeton de contexte SharePoint dans ce flux. Au lieu de cela, lorsque le complément s’exécute et tente d’accéder à SharePoint, SharePoint invite l’utilisateur à accorder des autorisations à l’application qu’il demande. Lorsque l’utilisateur octroie les autorisations, SharePoint obtient un code d’autorisation auprès d’ACS et le transmet à l’application. L’application utilise le code pour obtenir un jeton d’accès auprès d’ACS et peut ensuite l’utiliser pour communiquer avec SharePoint.

    Pour plus d’informations sur ce flux, reportez-vous à la rubrique Flux OAuth avec code d’autorisation pour les compléments SharePoint.

Dépannage des compléments SharePoint à faible niveau de confiance

Cet article fournit des informations et des conseils de dépannage généraux sur certains problèmes spécifiques avec les compléments SharePoint qui utilisent le système d’autorisation à faible niveau de confiance.

Utilisation de l’outil Fiddler

L’outil Fiddler gratuit peut être utilisé pour capturer les demandes HTTP envoyées par le composant à distance de votre complément à SharePoint. Il existe une extension gratuite de l’outil qui décode automatiquement les jetons d’accès dans les requêtes.

Désactiver l’obligation d’utiliser le protocole HTTPS pour OAuth lors du développement

OAuth a besoin que SharePoint exécute le protocole HTTPS (pas uniquement votre service, mais SharePoint également). Ceci peut constituer un obstacle quand vous développez le complément. Par exemple, vous pouvez recevoir un message 403 (interdit) lorsque vous tentez d’effectuer un appel vers SharePoint lors du débogage du complément, car la prise en charge SSL n’est pas présente dans le « localhost » sur lequel votre complément est exécuté.

Vous pouvez désactiver l’exigence HTTPS lors du développement à l’aide des cmdlets Windows PowerShell suivantes :

$serviceConfig = Get-SPSecurityTokenServiceConfig
$serviceConfig.AllowOAuthOverHttp = $true
$serviceConfig.Update()

Pour réactiver l’exigence HTTPS ultérieurement, utilisez les cmdlets Windows PowerShell suivantes :

$serviceConfig = Get-SPSecurityTokenServiceConfig
$serviceConfig.AllowOAuthOverHttp = $false
$serviceConfig.Update()

Si les noms de domaine dans les fichiers de configuration et les formulaires d'inscription ne correspondent pas, l'autorisation peut être bloquée. Les quatre valeurs suivantes doivent être identiques :

  • Le domaine de complément qui est spécifié lorsque le complément SharePoint est inscrit auprès de AppRegNew.aspx ou du tableau de bord vendeur.

  • Le domaine sous lequel le certificat de sécurité de l’application web distante est enregistré.

  • La partie de domaine de la valeur StartPage dans le fichier AppManifest.xml.

  • La partie du domaine de l’URL de tout récepteur d’événements spécifiés dans le fichier AppManifest.xml.

Dans ce contexte, notez les points suivants :

  • Si le composant distant de votre complément SharePoint utilise un port autre que le port 443, vous devez inclure explicitement le port en tant que partie du domaine dans les quatre endroits. Par exemple, contoso.com:3333. (Vous devez utiliser le protocole HTTPS pour lequel le port par défaut est le port 443.)

  • Si vous créez un alias CNAME DNS pour votre application web distante, utilisez l'alias CNAME pour la valeur de domaine aux quatre emplacements. Par exemple, si votre application est hébergée sur contoso.cloudapp.net et que vous lui créez un CNAME sur contososoftware.com, utilisez contososoftware.com comme domaine.

  • Le domaine doit être codé en dur dans la valeur StartPage (et toutes les URL de récepteur d’événement) du fichier AppManifest.xml avant que le complément ne soit packagé. Si vous utilisez l’Assistant Publication dans Visual Studio pour packager le complément, vous êtes invité à indiquer le domaine, et les outils de développement Office pour Visual Studio l’insèrent dans la valeur StartPage à votre place (à la place du jeton ~remoteWebUrl utilisé au cours du débogage). Mais si vous n’utilisez pas l’Assistant Publication, ou même si vous le faites mais que votre application web distante est déployée sur Azure, vous devez remplacer manuellement le jeton par le domaine (et le protocole) ; par exemple, https://contososoftware.com ou https://MyCloudVM:3333.

Erreur « La connexion sous-jacente a été fermée : impossible d’établir une relation de confiance pour le canal sécurisé SSL/TLS. »

Cette erreur révèle un problème d'établissement de liaison SSL et non un problème OAuth. Assurez-vous que le certificat que vous utilisez est approuvé par SharePoint et que ce certificat correspond au nom du point de terminaison.

Erreurs lors de l’utilisation de la méthode HTTP DAV pour lire des fichiers à partir de SharePoint

La méthode DAV HTTP ne fonctionne pas avec OAuth. Si vous utilisez le modèle objet client SharePoint (CSOM), utilisez le code suivant pour lire un fichier.

File f = clientContext.Web.GetFileByServerRelativeUrl( url);
ClientResult<Stream> r = f.OpenBinaryStream();
clientContext.ExecuteQuery();

Voir aussi