Création de compléments SharePoint qui utilisent l’autorisation avec un niveau de confiance élevé

  • Article

Un complément à haut niveau de fiabilité est un Complément SharePoint hébergé par un fournisseur qui est installé sur une batterie de serveurs SharePoint. Il ne peut pas être installé sur Microsoft SharePoint Online ou commercialisé sur l'Office Store. Un complément à haut niveau de fiabilité utilise un certificat à la place d’un jeton de contexte pour établir une approbation.

Remarque

Cette rubrique vous aide à comprendre le système d’autorisation à haut niveau de fiabilité pour les compléments SharePoint. Pour obtenir des informations pratiques sur la création et le déploiement de compléments à haut niveau de fiabilité, consultez les rubriques suivantes :

Dans SharePoint, le service d’émission de jeton de sécurité (STS) fournit des jetons d’accès pour l’authentification de serveur à serveur. Le STS permet aux jetons d’accès temporaire d’accéder à d’autres services d’application tels qu’Exchange, Lync et les compléments SharePoint. Un administrateur de batterie de serveurs établit l’approbation entre SharePoint et l’autre application ou complément à l’aide des cmdlets Windows PowerShell et d’un certificat. Chaque certificat utilisé doit être approuvé par SharePoint à l’aide de l’applet de New-SPTrustedRootAuthority commande . Par ailleurs, chaque certificat doit être enregistré auprès de SharePoint en tant qu’émetteur de jeton à l’aide de la cmdlet New-SPTrustedSecurityTokenIssuer.

Remarque

Le service STS n’est pas destiné à l’authentification des utilisateurs. C’est pour cette raison que ce service ne figure pas 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.

Deux types d’émetteurs de jeton

L’application web distante d’un complément SharePoint à haut niveau de fiabilité est liée à un certificat numérique. (Pour plus d’informations sur cette opération, reportez-vous aux deux rubriques liées précédentes). Le certificat est utilisé par l’application web distante pour signer les jetons d’accès qu’il inclut dans toutes ses requêtes à SharePoint. L’application web signe le jeton avec la clé privée du certificat, et SharePoint le valide avec la clé publique du certificat. Le certificat doit être inscrit en tant qu’émetteur approuvé de jetons pour que SharePoint approuve les jetons qu’il émet.

Il existe deux types d’émetteurs de jetons : certains d’entre eux peuvent uniquement émettre des jetons pour un complément SharePoint spécifique ; d’autres, nommés courtiers d’approbation, peuvent émettre des jetons pour plusieurs compléments SharePoint.

Pour plus de commodité, les administrateurs de batterie de serveurs SharePoint déterminent le type d’émetteur de jeton créé au moyen des commutateurs et des valeurs de paramètres qu’ils utilisent avec la cmdlet New-SPTrustedSecurityTokenIssuer. Pour créer un émetteur de jeton qui est un courtier d’approbation, ajoutez le commutateur -IsTrustBroker à la ligne de commande et utilisez une valeur unique autre qu’un ID client de complément pour le paramètre -Name. Un exemple modifié est fourni ci-dessous.

New-SPTrustedSecurityTokenIssuer -IsTrustBroker -RegisteredIssuerName "<full_token_issuer_name> " --other parameters omitted--

Pour créer un émetteur de jeton non courtier, le commutateur -IsTrustBroker n’est pas utilisé. Il existe une autre différence. La valeur du paramètre -RegisteredIssuerName prend toujours la forme de deux GUID séparés par le caractère « @ » ; GUID@GUID. Le GUID de droite est toujours l’ID du domaine d’authentification de la batterie de serveurs SharePoint (ou de l’abonnement au site). Le GUID de gauche est toujours l’ID spécifique d’un émetteur de jeton.

Il s’agit d’un GUID aléatoire lorsque c’est un émetteur de jeton courtier d’approbation qui est créé. En revanche, lorsqu’un émetteur de jeton non courtier est créé, le GUID de l’émetteur spécifique doit être le même que celui utilisé comme ID Client du complément SharePoint. Ce paramètre fournit un nom pour l’émetteur. Il indique également à SharePoint le complément SharePoint unique pour lequel le certificat peut émettre des jetons. Un exemple partiel est présenté ci-dessous :

$fullIssuerIdentifier = "<client_ID_of_SP_app> " + "@" + "<realm_GUID> "
New-SPTrustedSecurityTokenIssuer -RegisteredIssuerName $fullIssuerIdentifier --other parameters omitted--

Généralement, la cmdlet New-SPTrustedSecurityTokenIssuer est utilisée dans un script qui effectue d’autres tâches pour configurer les compléments SharePoint à haut niveau de fiabilité. Pour plus d’informations sur ces scripts et des exemples complets de la cmdlet New-SPTrustedSecurityTokenIssuer, reportez-vous à la rubrique Scripts de configuration à haut niveau de fiabilité pour SharePoint.

Choisir entre l’utilisation d’un certificat ou de nombreux compléments SharePoint à haut niveau de fiabilité

SharePoint et les administrateurs réseau peuvent choisir parmi deux stratégies de base lors de l’obtention et la gestion de certificats pour des compléments SharePoint à haut niveau de fiabilité :

  • Utilisez le même certificat pour plusieurs compléments SharePoint.

  • Utiliser un certificat distinct pour chaque Complément SharePoint.

Cet article aborde les avantages et les inconvénients de chaque stratégie.

L’utilisation d’un même certificat pour plusieurs compléments SharePoint offre à un administrateur l’avantage d’avoir moins certificats à approuver et à gérer. En revanche, dans le cas d’une situation où vous souhaitez interrompre l’approbation d’un complément SharePoint en particulier, cette approche présente l’inconvénient d’obliger l’administrateur à supprimer le certificat des émetteurs de jeton ou des autorités racine. Toutefois, la suppression du certificat interrompt également l’approbation de tous les autres compléments SharePoint qui utilisent le même certificat et entraîne donc l’arrêt de leur fonctionnement.

Pour que les compléments SharePoint encore dignes de confiance fonctionnent à nouveau, l’administrateur doit créer un New-SPTrustedSecurityTokenIssuer objet à l’aide d’un nouveau certificat et inclure l’indicateur -IsTrustBroker . Le nouveau certificat devra être réinscrit auprès de chaque serveur qui héberge les compléments dignes de confiance et chacun d’entre eux devra être lié au nouveau certificat.

L’utilisation d’un seul certificat par complément offre l’avantage de faciliter l’arrêt de l’approbation d’un complément en particulier, puisque les certificats utilisés par les compléments toujours dignes de confiance ne sont pas affectés lorsque l’administrateur interrompt l’approbation de ce complément spécifique. L’inconvénient de cette stratégie est qu’elle oblige un administrateur à acquérir un plus grand nombre de certificats et que SharePoint doit être configuré pour utiliser chacun d’entre eux, cette opération pouvant être réalisée à l’aide d’un script réutilisable, comme indiqué dans Scripts de configuration à haut niveau de fiabilité pour SharePoint .

Les certificats sont des autorités racine dans SharePoint

Comme il a été brièvement mentionné au début de cet article, les administrateurs de batteries de serveurs SharePoint doivent déclarer le certificat de l’application web distante du complément à haut niveau de fiabilité en tant qu’autorité racine approuvée dans SharePoint, ainsi qu’en tant qu’émetteur de jeton approuvé. En fait, lorsque le certificat de l’application web est pris en charge par une hiérarchie d’autorités d’émission de certificats, tous les certificats de la chaîne doivent être ajoutés à la liste d’autorités racine approuvées de SharePoint.

Chaque certificat de la chaîne est ajouté à la liste des autorités racines approuvées de SharePoint avec un appel de l’applet New-SPTrustedRootAuthority de commande. Par exemple, supposons que le certificat de l'application web est un certificat de domaine délivré par une autorité de certification du domaine d'entreprise sur le réseau local, et supposons que son certificat, à son tour, a été publié par une autorité de certification autonome de niveau supérieur sur le réseau local. Dans ce cas, les certificats de l'autorité de certification de niveau supérieur, de l'autorité de certification intermédiaire, ainsi que de l'application web doivent tous être ajoutés à la liste des autorités racines approuvées de SharePoint. Le code Windows PowerShell suivant se charge d'accomplir cette tâche.

$rootCA = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("<path_to_top-level_CA's_cer_file>")
New-SPTrustedRootAuthority -Name "<name_of_certificate>" -Certificate $rootCA

$intermediateCA = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("path_to_intermediate_CA's_cer_file")
New-SPTrustedRootAuthority -Name "<name_of_certificate>" -Certificate $intermediateCA

$certificate = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("path_to_web_application's_cer_file") 
New-SPTrustedRootAuthority -Name "<name_of_certificate>" -Certificate $certificate

Les certificats racine et intermédiaires doivent uniquement être ajoutés une fois dans une batterie de serveurs SharePoint. En règle générale, le certificat de l’application web est ajouté dans un script distinct qui effectue également d’autres tâches de configuration, telles que l’appel à New-SPTrustedSecurityTokenIssuer. Pour obtenir des exemples, reportez-vous à Scripts de configuration à haut niveau de fiabilité pour SharePoint.

Si le certificat de l’application web est auto-signé, comme cela pourrait être le cas lorsque le complément est en cours de développement et de débogage, il n’y a pas de chaîne de certificats et seul le certificat de l’application web doit être ajouté à la liste des autorités racines.

Pour plus d’informations, reportez-vous au billet de blog concernant l’ erreur liée à une racine de chaîne de certificats non approuvée avec l’authentification basée sur les revendications. Faites défiler la page au-delà de la section sur l’exportation du certificat à partir d’Active Directory Federation Services (AD FS), à condition que vous ayez créé le certificat de vos compléments à niveau de fiabilité élevé par d’autres moyens, notamment en utilisant un certificat commercial émis par une autorité de certification, un certificat auto-signé ou un certificat émis par un domaine.

L’application web doit savoir qu’il s’agit d’un émetteur de jeton

Le composant Application web distante du complément SharePoint est lié à son certificat dans IIS. Cela s’avère suffisant pour la fonction traditionnelle des certificats, à savoir identifier l’application web et encoder les demandes et les réponses HTTP en toute sécurité.

Toutefois, dans un complément SharePoint à haut niveau de fiabilité, le certificat est également chargé d’être « l’émetteur » officiel des jetons d’accès que l’application web envoie à SharePoint. À cet effet, l’application web doit connaître l’ID d’émetteur du certificat utilisé lors de l’inscription de ce certificat en tant qu’émetteur de jetons auprès de SharePoint. L’application web obtient cet ID dans la section appSettings du fichier web.config, où il existe une clé nommée IssuerId.

Les instructions indiquant au développeur de compléments comment définir cette valeur, et comment le certificat est lié à l’application web dans IIS, sont fournies dans Empaquetage et publication de compléments SharePoint à haut niveau de fiabilité.

Notez que si le client suit la stratégie consistant à utiliser un certificat distinct pour chaque complément SharePoint à haut niveau de fiabilité, la valeur de ClientId est également utilisée pour IssuerId. Cela n’est pas le cas lorsque plusieurs compléments partagent le même certificat, car chacun d’entre eux doit avoir son propre ID Client unique, mais l’ID de l’émetteur est l’identificateur pour un objet SPTrustedSecurityTokenIssuer.

Voici un exemple de section appSettings pour un Complément SharePoint à haut niveau de fiabilité. Dans cet exemple, plusieurs compléments partagent un certificat, de sorte que l'élément IssuerId est différent de l'élément ClientId. Notez qu'il n'y a pas de clé ClientSecret dans un Complément SharePoint à haut niveau de fiabilité.

<appSettings>
  <add key="ClientId" value="6569a7e8-3670-4669-91ae-ec6819ab461" />
  <add key="ClientSigningCertificatePath" value="C:\MyCerts\HighTrustCert.pfx" />
  <add key="ClientSigningCertificatePassword" value="3VeryComplexPa$$word82" />
  <add key="IssuerId" value="e9134021-0180-4b05-9e7e-0a9e5a524965" />
</appSettings>

Remarque

L’exemple qui précède suppose que le certificat est stocké dans le système de fichiers. Ceci est acceptable à des fins de développement et de débogage. Dans un complément SharePoint à haut niveau de fiabilité de production, le certificat est généralement stocké dans le magasin de certificats Windows, et les clés ClientSigningCertificatePath et ClientSigningCertificatePassword sont généralement remplacées par une clé ClientSigningCertificateSerialNumber.

Responsabilités du personnel IT dans le système à haut niveau de fiabilité

Les développeurs doivent comprendre les exigences relatives à la sécurité des applications décrites ci-dessus, mais ce sont les professionnels de l’informatique qui implémentent l’infrastructure nécessaire pour prendre en charge ces exigences. Ils doivent donc prévoir les éléments suivants :

  • Créer ou acheter un ou plusieurs certificats qui seront utilisés pour les compléments SharePoint approuvés.

  • Vérifier que les certificats sont stockés en toute sécurité sur les serveurs d’application web. Lorsque le système d’exploitation Windows est utilisé, cela implique de stocker les certificats dans le magasin de certificats Windows.

  • Gérez la distribution de ces certificats aux développeurs qui créent des compléments SharePoint.

  • Gardez une trace des emplacements où chaque certificat est distribué, aussi bien pour les compléments qui l’utilisent que pour les développeurs qui en ont reçu une copie. Si un certificat doit être révoqué, le service informatique doit travailler avec chaque développeur pour organiser une transition gérée vers un nouveau certificat.

Voir aussi