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

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. Pour établir une connexion sécurisée, un complément à haut niveau de fiabilité utilise un certificat au lieu d'un jeton de contexte.

Notes

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 au moyen de la cmdlet New-SPTrustedRootAuthority. Par ailleurs, chaque certificat doit être enregistré auprès de SharePoint en tant qu’émetteur de jeton à l’aide de la cmdlet New-SPTrustedSecurityTokenIssuer.

Notes

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.

En pratique, les administrateurs de batterie de serveurs SharePoint déterminent le type d’émetteur de jeton créé par les commutateurs et les valeurs de paramètre qu’ils utilisent avec l’applet de commande New-SPTrustedSecurityTokenIssuer . Pour créer un émetteur de jeton qui est un répartiteur de confiance, ajoutez le commutateur -IsTrustBroker à la ligne de commande et utilisez une valeur unique, autre que l’ID client d’un complément, pour le paramètre -Name . Voici un exemple modifié.

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’avantage d’utiliser le même certificat pour plusieurs compléments SharePoint est qu’un administrateur a moins de certificats à approuver et à gérer. L’inconvénient de cette approche est que, lorsque vous rencontrez une situation où vous souhaitez rompre l’approbation avec un complément SharePoint particulier, la seule façon pour l’administrateur de rompre l’approbation consiste à supprimer le certificat en tant qu’émetteur de jeton ou en tant qu’autorité racine. Toutefois, la suppression du certificat interrompt également l’approbation avec tous les autres compléments SharePoint qui utilisent le même certificat, ce qui les amène tous à cesser de fonctionner.

Pour que les compléments SharePoint toujours approuvés puissent recommencer à fonctionner, l’administrateur doit alors créer un objet New-SPTrustedSecurityTokenIssuer au moyen d’un nouveau certificat et y 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’avantage de l’utilisation d’un certificat par complément est qu’il est plus facile de rompre l’approbation avec un complément particulier, car les certificats utilisés par les compléments toujours fiables ne sont pas affectés lorsque l’administrateur interrompt l’approbation avec le certificat d’un complément. L’inconvénient de cette stratégie est qu’un administrateur a plus de certificats à acquérir et que SharePoint doit être configuré pour utiliser chacun d’eux, ce qui peut être fait avec 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 mentionné brièvement en haut de cet article, les administrateurs de batterie de serveurs SharePoint doivent faire du certificat de l’application web distante dans le complément à haut niveau de fiabilité une autorité racine approuvée dans SharePoint, ainsi qu’un émetteur de jeton approuvé. En fait, lorsqu’il existe une hiérarchie d’autorités émettrices de certificats derrière le certificat de l’application web, tous les certificats de la chaîne doivent être ajoutés à la liste des autorités racines 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 de commande New-SPTrustedRootAuthority. 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 racines et intermédiaires ne doivent être ajoutés qu’une seule fois sur 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 configurations, telles que l’appel à New-SPTrustedSecurityTokenIssuer. Pour obtenir des exemples, consultez 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, consultez le billet de blog racine de la chaîne de certificats Erreur non approuvée avec l’authentification par revendications. Faites défiler la section sur l’exportation du certificat à partir de Active Directory Federation Services (AD FS), en supposant que vous avez créé votre certificat pour vos compléments à haut niveau de fiabilité par d’autres moyens ; par exemple, à l’aide d’un certificat commercial émis par une autorité de certification, d’un certificat auto-signé ou d’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>

Notes

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 en matière de sécurité des applications, comme décrit précédemment, mais les professionnels de l’informatique implémentent l’infrastructure nécessaire pour la prendre en charge. Les professionnels de l’informatique doivent planifier les exigences opérationnelles suivantes :

  • 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