Trois systèmes d’autorisation pour les compléments SharePoint

Dans SharePoint, un complément SharePoint est une identité de principal, comme un utilisateur, et doit être authentifié et autorisé à employer les ressources SharePoint. Il existe trois systèmes d’autorisation qui peuvent être utilisés par un complément. Ils ne s’excluent pas mutuellement.

Comprendre les trois systèmes d’autorisation et quand les utiliser

Confiance basse

Un complément SharePoint hébergé par un fournisseur peut s’inscrire auprès de Microsoft Azure Access Control Service (ACS), qui émet un jeton d’accès pour le complément afin de l’autoriser à accéder aux ressources de la batterie de serveurs ou du client SharePoint sur lequel il est installé. ACS Azure est l’émetteur de jeton de confiance dans un « flux » OAuth 2.0 Framework qui inclut SharePoint et les composants distants du complément. Les compléments qui utilisent ce système peuvent être vendus dans l’Office Store. Le système à faible niveau de confiance est principalement destiné aux compléments dont les composants distants sont hébergés dans le cloud.

Pour plus d’informations sur la création d’un complément SharePoint qui utilise le système à faible niveau de confiance, reportez-vous à la rubrique Création de compléments pour SharePoint qui utilisent l’autorisation de confiance basse.

Haut niveau de fiabilité

Un complément hébergé par un fournisseur peut établir la confiance avec SharePoint au moyen de certificats numériques. Le système à haut niveau de fiabilité est principalement destiné aux compléments dont les composants distants sont hébergés localement. Le complément peut être installé sur une batterie de serveurs SharePoint qui n’est pas connectée à Internet. Le complément ne peut pas être installé sur SharePoint Online ou vendu dans l’Office Store.

Pour plus d’informations sur la création d’un complément SharePoint qui utilise le système à haut niveau de fiabilité, reportez-vous à la rubrique Création de compléments pour SharePoint qui utilisent l’autorisation à haut niveau de fiabilité.

Bibliothèque inter-domaines

Lorsque la logique métier du complément est dans JavaScript, vous avez la possibilité d’utiliser la bibliothèque inter-domaines de SharePoint à la place ou en plus des systèmes de confiance basse ou à niveau élevé de fiabilité. La bibliothèque est également conçue pour les scénarios avec lesquels le complément a des composants hébergés dans le cloud, mais où le pare-feu d’entreprise du client rend difficile l’utilisation du système à faible niveau de confiance. Le navigateur de l’utilisateur bloque les scripts provenant d’autres domaines, mais la bibliothèque encapsule un système sécurisé permettant de contourner cette restriction. Les compléments qui utilisent la bibliothèque peuvent être vendus dans l’Office Store et peuvent être installées sur SharePoint Online ou sur SharePoint en local.

Pour en savoir plus sur la création d’un complément SharePoint qui utilise la bibliothèque inter-domaines, reportez-vous à :

• Création de compléments SharePoint qui utilisent la bibliothèque inter-domaines

• Résoudre les problèmes inter-domaines dans les compléments SharePoint (billet de blog)

Informations générales sur l’infrastructure OAuth 2.0 et son implémentation SharePoint

Deux des trois systèmes d’autorisation utilisent OAuth 2.0 Framework. OAuth 2.0 est une infrastructure ouverte d’autorisation. OAuth rend possible une autorisation sécurisée standard à partir d’applications de bureau, d’appareils et sur le web. OAuth permet à un utilisateur d’approuver une application agissant en son nom sans partager son nom d’utilisateur et son mot de passe.

Par exemple, elle permet à un utilisateur de partager ses ressources ou données privées (liste de contacts, documents, photos, vidéos, etc.) issues d’un site avec un autre site sans que l’utilisateur ne soit obligé de fournir ses informations d’identification (généralement un nom d’utilisateur et un mot de passe) à l’autre site.

OAuth permet aux utilisateurs de fournir des jetons d’accès aux données hébergées par un fournisseur de services donné (par exemple, SharePoint). Chaque jeton octroie l’accès à un fournisseur de ressources spécifique (par exemple, un site web SharePoint), pour des ressources spécifiques (par exemple, les documents d’une bibliothèque de documents SharePoint) pendant une durée définie (par exemple, 12 heures). Ainsi, un utilisateur peut octroyer à une application web ou de bureau un accès à des informations stockées chez un autre fournisseur de services ou de ressources (par exemple, SharePoint) sans partager son nom d’utilisateur et son mot de passe, et sans partager toutes les données dont il dispose chez le fournisseur.

SharePoint utilise les « flux » de transmission de jeton de l’infrastructure OAuth 2.0 pour :

• Autoriser les demandes d’un complément SharePoint pour accéder aux ressources SharePoint.

• Authentifier les compléments dans l’Office Store, un catalogue de complément ou un client développeur.

Pour plus d’informations et de contexte sur OAuth et la terminologie OAuth, consultez OAuth.net et Protocole d’autorisation web (oauth).

En résumé, il existe un serveur de ressources qui héberge une ressource protégée, un propriétaire de la ressource, une application cliente qui cherche à accéder à la ressource et un serveur d’autorisation qui émet des jetons d’accès à la ressource lorsque le propriétaire de la ressource lui en donne l’instruction.

La documentation OAuth officielle est basée sur un scénario selon lequel il n’existe qu’un seul propriétaire de la ressource, qui octroie un accès à la ressource à partir de l’application cliente à chaque exécution de l’application cliente. Elle présuppose également que la personne qui utilise l’application cliente est le propriétaire de la ressource.

L’implémentation SharePoint tient compte du fait qu’une ressource SharePoint, telle qu’une liste, est partagée entre plusieurs utilisateurs. Par ailleurs, dans l’implémentation SharePoint, l’accès est accordé au complément SharePoint lors de son installation et non à chaque exécution, et il peut être exécuté par d’autres utilisateurs que la personne qui l’a installé et lui a accordé les droits d’accès. (Dans le cas de compléments qui ne sont pas installées sur SharePoint, mais qui accèdent à des ressources SharePoint (et qui ne sont donc des « compléments SharePoint » qu’au sens large), l’utilisateur qui exécute le complément est tenu d’accorder les autorisations à chaque exécution du complément.)

Par conséquent, dans l’implémentation de SharePoint, les rôles OAuth sont joués par les éléments suivants :

• Le composant distant d’un complément SharePoint joue le rôle de l’application cliente.

• Les utilisateurs de SharePoint jouent le rôle de propriétaire de ressource.

• SharePoint joue le rôle de serveur de ressources.

• Azure ACS joue le rôle de serveur d’autorisation lorsque le système d’autorisation à faible niveau de confiance est utilisé. Lorsque le système à haut niveau de fiabilité est utilisé, le complément lui-même (ainsi qu’un fichier certificate.md numérique) devient le serveur d’autorisation.

Les jetons d’accès ne sont pas des jetons de connexion

Comme décrit précédemment, pour accéder aux ressources, un complément doit demander un jeton d’accès à un serveur d’autorisation OAuth ayant été précédemment désigné comme un STS approuvé par le propriétaire de la ressource. En revanche, le STS WS-Federation et le STS de connexion passive SAML sont principalement destinés à émettre des jetons de connexion.

Dans SharePoint, un STS OAuth n’est pas utilisé pour émettre des jetons de connexion ; autrement dit, il ne sert pas de fournisseur d’identité. C’est pour cette raison qu’aucun STS OAuth ne figure sur la page de connexion de l’utilisateur, dans la section Fournisseur d’authentification sur le site Administration centrale ou dans le sélecteur de personnes dans SharePoint.

Les administrateurs SharePoint peuvent utiliser les commandes Windows PowerShell pour activer ou désactiver un STS OAuth, de la même manière qu’ils peuvent activer ou désactiver les fournisseurs de connexions approuvés dans SharePoint.

Voir aussi

• Autorisation et authentification des compléments dans SharePoint
• Développer des compléments pour SharePoint