Vue d’ensemble de l’authentification pour SharePoint Server

  • Article

 

**Sapplique à :**SharePoint Server 2013, SharePoint Server 2016

**Dernière rubrique modifiée :**2017-06-21

Résumé : Découvrez le fonctionnement de l’authentification d’utilisateur, d’application et de serveur à serveur dans SharePoint Server 2013 et SharePoint Server 2016.

SharePoint Server nécessite une authentification pour les types d’interactions suivants :

  • Utilisateurs qui accèdent aux ressources SharePoint sur site

  • Applications qui accèdent aux ressources SharePoint sur site

  • Serveurs sur site qui accèdent aux ressources SharePoint sur site, et vice versa

Dans cet article :

  • Authentification utilisateur dans SharePoint Server 2016

  • Authentification d’application dans SharePoint Server

  • Authentification de serveur à serveur

Authentification utilisateur dans SharePoint Server 2016

L’authentification d’utilisateur est la validation de l’identité de l’utilisateur auprès d’un fournisseur d’authentification, c’est-à-dire un répertoire ou une base de données qui contient les informations d’identification de l’utilisateur et permet de vérifier qu’elles ont été entrées correctement. L’authentification d’utilisateur intervient lorsqu’un utilisateur tente d’accéder à une ressource SharePoint.

SharePoint Server prend en charge l’authentification basée sur les revendications.

Le résultat d’une authentification basée sur les revendications est un jeton de sécurité basé sur les revendications, généré par le service STS SharePoint (Security Token Service).

SharePoint Server prend en charge les authentifications de revendications Windows, basée sur les formulaires et basée sur un jeton SAML. Pour plus d’informations sur ces trois méthodes d’authentification, regardez les vidéos suivantes.

Notes

Les informations contenues dans les vidéos s’appliquent à SharePoint Server 2013 et SharePoint Server 2016.

Vidéo sur l’authentification basée sur les revendications Windows dans SharePoint Server 2013 et 2016

Vidéo sur l’authentification de revendications basée sur les formulaires dans SharePoint Server 2013 et 2016

Vidéo sur l’authentification de revendications basée sur un jeton SAML dans SharePoint Server 2013 et 2016

Pour plus d’informations, voir Planifier les méthodes d’authentification utilisateur dans SharePoint Server.

Authentification d’application dans SharePoint Server

L’authentification d’application est la validation de l’identité d’une application SharePoint distante et l’autorisation de l’application et d’un utilisateur associé d’une demande de ressource SharePoint sécurisée. L’authentification d’application intervient lorsqu’un composant externe d’une application Banque SharePoint ou de Catalogue d’applications, comme un serveur web situé sur l’intranet ou sur Internet, tente d’accéder à une ressource SharePoint sécurisée.

Supposons qu’un utilisateur ouvre une page SharePoint contenant un IFRAME d’une application SharePoint, et que cet IFRAME nécessite un composant externe, comme un serveur sur l’intranet ou sur Internet, pour accéder à une ressource SharePoint sécurisée pour afficher la page. Le composant externe de l’application SharePoint doit être authentifié et autorisé pour que SharePoint fournisse les informations demandées et que l’application puisse afficher la page pour l’utilisateur.

Notez que si l’application SharePoint ne nécessite pas de ressource SharePoint sécurisée pour afficher la page pour l’utilisateur, l’authentification d’application n’est pas nécessaire. Par exemple, une application SharePoint qui fournit des prévisions météorologiques et doit accéder uniquement à un serveur d’informations météorologiques sur Internet n’a pas besoin d’utiliser l’authentification d’application.

L’authentification d’application combine deux processus :

  • Authentification

    Vérification de l’enregistrement correct de l’application auprès d’un fournisseur d’identité approuvé

  • Autorisation

    Vérification que l’application et l’utilisateur associé disposent des autorisations appropriées pour effectuer une opération, par exemple accès à un dossier ou à une liste, exécution d’une demande

Pour s’authentifier, l’application obtient un jeton d’accès émis par le service de contrôle d’accès Microsoft Azure ou en signant elle-même un jeton d’accès à l’aide d’un certificat approuvé par SharePoint Server. Le jeton d’accès prouve une demande d’accès à une ressource SharePoint donnée et contient les informations d’identification de l’application et de l’utilisateur associé, en remplacement de la validation des informations d’identification de l’utilisateur. Le jeton d’accès n’est pas un jeton de connexion.

Voici un exemple de processus d’authentification pour les applications Banque SharePoint :

  1. Un utilisateur ouvre une page web SharePoint contenant un IFRAME qui doit être affiché par une application Banque SharePoint qui est hébergée sur Internet et utilise ACS comme fournisseur approuvé. Pour afficher l’IFRAME pour l’utilisateur, l’application Banque SharePoint doit accéder à une ressource SharePoint.

  2. Le service STS SharePoint demande et reçoit un jeton de contexte d’ACS.

  3. SharePoint envoie la page Web demandée avec le jeton de contexte au navigateur Web de l’utilisateur.

  4. Le navigateur Web de l’utilisateur envoie une demande pour le contenu de l’IFRAME et le jeton de contexte au serveur d’applications Banque SharePoint sur Internet.

  5. Le serveur d’applications Banque SharePoint demande et reçoit un jeton d’accès d’ACS.

  6. Le serveur d’applications Banque SharePoint envoie la demande de ressource SharePoint et le jeton d’accès au serveur SharePoint.

  7. Le serveur SharePoint autorise l’accès en vérifiant les autorisations de l’application, qui ont été spécifiées au moment de l’installation de l’application, et les autorisations de l’utilisateur associé.

  8. En cas d’autorisation, SharePoint envoie les données demandées au serveur d’applications Banque SharePoint sur Internet.

  9. Le serveur d’applications Banque SharePoint sur Internet envoie les résultats de l’IFRAME au navigateur web, qui affiche la partie IFRAME de la page pour l’utilisateur.

Observez comment l’application Banque SharePoint a accédé aux ressources de serveur SharePoint sans demander les informations d’identification de l’utilisateur. L’accès a été authentifié par ACS, qui est approuvé par le serveur qui exécute SharePoint Server, et autorisé par l’ensemble des autorisations d’utilisateur et d’application.

Voici un exemple de processus d’authentification pour les applications de Catalogue d’applications SharePoint :

  1. Un utilisateur ouvre une page web SharePoint contenant un IFRAME qui doit être affiché par une application de Catalogue d’applications qui est hébergée sur l’intranet et utilise un certificat autosigné pour ses jetons d’accès. Pour afficher l’IFRAME pour l’utilisateur, l’application de Catalogue d’applications doit accéder à une ressource SharePoint.

  2. SharePoint envoie la page demandée avec l’IFRAME au navigateur Web de l’utilisateur.

  3. Le navigateur Web de l’utilisateur envoie une demande pour le contenu de l’IFRAME au serveur d’applications de Catalogue d’applications sur l’intranet.

  4. Le serveur d’applications de Catalogue d’applications authentifie l’utilisateur et génère un jeton d’accès, signé avec son certificat auto-signé.

  5. Le serveur d’applications de Catalogue d’applications envoie la demande de ressource SharePoint et le jeton d’accès au serveur SharePoint.

  6. Le serveur SharePoint autorise l’accès en vérifiant les autorisations de l’application, qui ont été spécifiées au moment de l’installation de l’application, et les autorisations de l’utilisateur associé.

  7. En cas d’autorisation, le serveur SharePoint envoie les données demandées au serveur d’applications de Catalogue d’applications sur l’intranet.

  8. Le serveur d’applications de Catalogue d’applications envoie les résultats de l’IFRAME au navigateur Web, qui affiche la partie IFRAME de la page pour l’utilisateur.

Notes

Les applications de Catalogue d’applications peuvent utiliser ACS ou un certificat auto-signé pour leurs jetons d’accès.

Pour plus d’informations, voir Planifier l’authentification d’application dans SharePoint Server.

Authentification de serveur à serveur dans SharePoint Server

L’authentification de serveur à serveur est la validation d’une demande de ressources d’un serveur basée sur une relation d’approbation établie entre le STS du serveur qui exécute SharePoint Server et celui d’un autre serveur qui prend en charge le protocole de serveur à serveur OAuth, comme SharePoint Server, Exchange Server 2016, Skype Entreprise 2016 ou Azure Workflow Service s’exécutant en local et SharePoint Server s’exécutant dans Office 365. À partir de cette relation d’approbation, un serveur qui émet une demande peut accéder aux ressources sécurisées du serveur SharePoint pour un compte d’utilisateur donné, sous réserve des autorisations serveur et utilisateur.

Par exemple, un serveur qui exécute Exchange Server 2016 peut demander des ressources d’un serveur exécutant SharePoint Server pour un compte d’utilisateur donné. Ce n’est pas le cas avec l’authentification d’application, dans laquelle l’application n’a pas accès aux informations d’identification du compte d’utilisateur. L’utilisateur peut être connecté ou non au serveur qui effectue la demande de ressources, en fonction du service et de la demande.

Lorsqu’un serveur qui exécute SharePoint Server tente d’accéder à une ressource d’un serveur ou qu’un serveur tente d’accéder à une ressource sur un serveur qui exécute SharePoint Server, la demande d’accès entrant doit être authentifiée pour que le serveur accepte cette demande et les données associées. L’authentification de serveur à serveur vérifie que le serveur qui exécute SharePoint Server et l’utilisateur qu’il représente sont approuvés.

Le jeton utilisé pour l’authentification de serveur à serveur est un jeton de serveur à serveur, pas un jeton de connexion. Le jeton de serveur à serveur contient des informations sur le serveur qui demande l’accès et le sur le compte d’utilisateur pour lequel le serveur agit.

Voici un exemple de processus de base pour les serveurs sur site :

  1. Un utilisateur ouvre une page web SharePoint qui nécessite des informations d’un autre serveur (par exemple, affichage de la liste de tâches de SharePoint Server et d’Exchange Server 2016).

  2. SharePoint Server génère un jeton de serveur à serveur.

  3. SharePoint Server envoie ce jeton à l’autre serveur.

  4. L’autre serveur valide le jeton de serveur à serveur SharePoint.

  5. L’autre serveur envoie un message à SharePoint Server pour indiquer que le jeton de serveur à serveur est valide.

  6. Le service sur le serveur qui exécute SharePoint Server accède aux données sur le serveur.

  7. Le service sur le serveur qui exécute SharePoint Server affiche la page pour l’utilisateur.

Voici un exemple de processus pour illustrer le cas où les deux serveurs fonctionnent dans Office 365 :

  1. Un utilisateur ouvre une page Web SharePoint qui nécessite des informations d’un autre serveur (par exemple, affichage de la liste de tâches de SharePoint Online et d’Exchange Online).

  2. SharePoint Online demande et reçoit un jeton de serveur à serveur d’ACS.

  3. SharePoint Online envoie le jeton de serveur à serveur au serveur Office 365.

  4. Le serveur Office 365 vérifie l’identité de l’utilisateur dans le jeton de serveur à serveur avec ACS.

  5. Le serveur Office 365 envoie un message à SharePoint Online pour indiquer que le jeton de serveur à serveur est valide.

  6. Le service sur SharePoint Online accède aux données sur le serveur Office 365.

  7. Le service sur SharePoint Online affiche la page pour l’utilisateur.

Pour plus d’informations, voir Planifier l’authentification de serveur à serveur dans SharePoint Server.