Configuration d’une approbation oAuth entre des batteries de serveurs dans SharePoint 2013
Article original publié le lundi 23 juillet 2012
Il est probable que vous allez entendre beaucoup parler d’oAuth dans SharePoint 2013, et il est possible que j’écrive beaucoup à ce sujet. Dans SharePoint 2013, oAuth sert à établir une approbation entre deux applications afin d’établir l’identité d’un principal (d’utilisateur ou d’application). Sans SharePoL’article original se trouve à l’adresse int, vous allez utiliser les approbations oAuth entre SharePoint et des entités comme Exchange et Lync, avec ACS ou des développeurs d’applications individuelles qui utilisent le nouveau modèle d’application dans le cloud, voire même entre deux batteries de serveurs SharePoint pour des choses comme la fonction d’index SharePoint distant dans la recherche.
En revanche, oAuth NE devient PAS un fournisseur d’authentification pour les personnes ; vous allez continuer d’utiliser votre New-SPTrustedIdentityTokenIssuer pour créer ces approbations à vos fournisseurs d’identité. Pour les approbations oAuth, on utilise une nouvelle applet de commande au nom très similaire de New-SPTrustedSecurityTokenIssuer. Après avoir établi ce type d’approbation avec un émetteur de jeton de sécurité, nous l’appelons une approbation S2S, qui signifie « de serveur à serveur ». Souvenez-vous de cet acronyme, car vous allez le rencontrer très souvent dans SharePoint 2013. Dans cet article, je vais aborder certaines des particularités nécessaires à la création de cette approbation
Tout d’abord, il est intéressant de noter que de nombreuses fonctions qui nécessitent une approbation S2S vont l’établir elles-mêmes. Elles peuvent le faire par activation de fonctions, ou des équipes associées aux fonctions peuvent vous fournir un script ou une applet de commande PowerShell à exécuter, qui crée l’approbation dans le cadre de l’activation de fonction. Dans d’autres cas, vous devrez le faire vous-même. Cet article est consacré à cette situation.
Une des questions à résoudre en premier concerne l’utilisation ou non de SSL. En réalité, dans la plupart des cas avec SharePoint 2013, il est sans doute préférable d’utiliser SSL. Pourquoi ? Parce que de nombreux scénarios utilisent oAuth dans SharePoint 2013, et dans ces situations, vous transmettez un cookie contenant un jeton d’accès. Ce jeton d’accès est comme une clé qui déverrouille la porte des données. Bien qu’il soit signé par un certificat qui le protège des falsifications par les personnes qui créent leur propre jeton d’accès, vous ne voulez pas le voir se promener en texte clair car quelqu’un pourrait théoriquement récupérer ce cookie et le réutiliser pendant sa durée de vie. SSL vous protège de cette attaque par relecture de cookie, de la même manière que lorsque vous utilisez SSL avec un site à authentification basée sur les formulaires. Cela étant, il existe toujours des raisons pour lesquelles vous pouvez souhaiter exécuter vos sites sur HTTP : par exemple, vous êtes dans un environnement de test, vous êtes en train de créer un environnement de développement, vous ne quittez jamais un réseau interne et le considérez sans risque, etc. Je ne suis pas là pour juger, seulement pour expliquer.
ÉTAPE 1 : Configuration du service d’émission de jeton de sécurité
Si vous voulez, vous pouvez modifier deux paramètres dans la configuration du service d’émission de jeton de sécurité (STS) de SharePoint si vous n’utilisez pas SSL. Vous pouvez obtenir tous les paramètres de configuration avec cette applet de commande Get-SPSecurityTokenServiceConfig. Il existe deux moyens d’obtenir une approbation : en utilisant un certificat, ou en utilisant un nouveau point de terminaison de métadonnées oAuth que possèdent toutes les batteries de serveurs SharePoint. Le recours au point de terminaison de métadonnées est la méthode la plus simple, mais si ce point de terminaison n’est pas sécurisé par SSL, alors vous devez définir la propriété AllowMetadataOverHttp du service STS de SharePoint sur True (vrai). Si vous ne prévoyez pas d’exécuter vos applications Web sur SSL, alors vous devez aussi définir la propriété AllowOAuthOverHttp sur true. Voici une petite applet de commande PowerShell qui indique comment définir ces propriétés :
$c = Get-SPSecurityTokenServiceConfig
$c.AllowMetadataOverHttp = $true
$c.AllowOAuthOverHttp= $true
$c.Update()
ÉTAPE 2 : Création de l’approbation
Une fois le service STS configuré comme nécessaire, nous pouvons examiner comment établir l’approbation d’une batterie de serveurs à une autre. Comme mentionné plus haut, toutes les batteries de serveurs SharePoint possèdent un point de terminaison de métadonnées servant à fournir des informations ainsi que le certificat de signature de jeton de sécurité. Ce point de terminaison de métadonnées se trouve dans /_layouts/15/metadata/json/1. Si vous accédez à ce fichier dans un navigateur, vous serez invité à l’enregistrer, ce que vous pouvez faire pour l’examiner. Si vous l’ouvrez dans le Bloc-notes, vous découvrirez qu’il s’agit juste d’une charge utile JSON. Il contient l’identificateur de nom du service STS (qu’il appelle « issuer »), ainsi qu’une version sérialisée du certificat de signature de jeton (qu’il désigne par « value » pour la clé « x509certificate »). Si vous consultez les données plus loin, vous verrez que « issuer » correspond en fait à nom_service + « @ » + valeurs du domaine. Il correspond également à la propriété NameIdentifier sur le service STS . Ce détail est important, comme je vais l’expliquer plus loin.
Supposons dans cet exemple que BATTERIE_B doit approuver les appels de BATTERIE_A, car BATTERIE_A va utiliser BATTERIE_B comme index SharePoint distant. Supposons également que BATTERIE_A possède une application Web à l’adresse https://BATTERIE_A. Pour créer l’approbation, on exécute l’applet de commande New-SPTrustedSecurityTokenIssuer sur un serveur de BATTERIE_B comme suit (je vais expliquer pourquoi j’utilise « $i = » plus loin dans l’article :
$i = New-SPTrustedSecurityTokenIssuer -Name BATTERIE_A -Description "Description BATTERIE_A" -IsTrustBroker:$false -MetadataEndPoint "https://BATTERIE_A/_layouts/15/metadata/json/1"
Maintenant, supposons que vous configurez une approbation avec une batterie de serveurs de services uniquement. Vous ne voulez pas créer d’application Web, de collection de sites et de certificat SSL seulement pour pouvoir créer une approbation à partir de lui. Par conséquent, on dispose d’une deuxième méthode utilisable pour établir l’approbation à l’aide de l’applet de commande New-SPTrustedSecurityTokenIssuer. Dans le deuxième formulaire, il vous suffit de fournir le certificat de signature de jeton et l’identificateur de nom. Pour obtenir le certificat de signature de jeton, procédez exactement comme dans SharePoint 2010 : sur un serveur de la batterie, exécutez la console MMC, ajoutez le composant logiciel enfichable Certificats pour l’ordinateur local, recherchez dans le nœud SharePoint…Certificats, et le premier certificat de la liste est celui que vous recherchez. Enregistrez-le sur le disque local sans la clé privée en tant que fichier .cer. Il vous faut le certificat et l’attribut NameIdentifier du service STS décrit plus haut pour pouvoir établir l’approbation. Dans ce cas, l’applet de commande prend la forme suivante (elle suppose que vous avez copié le certificat STS dans un fichier nommé C:\sts.cer sur un serveur de BATTERIE_B):
$i = New-SPTrustedSecurityTokenIssuer -name BATTERIE_A -Certificate "C:\sts.cer" -RegisteredIssuerName "00000003-0000-0ff1-ce00-000000000000@72da1552-085a-49de-9ecb-73ba7eca8fef " -Description "Description BATTERIE_A" -IsTrustBroker:$false
ÉTAPE 3 : Approbation du certificat de signature de jeton
Comme pour SPTrustedIdentityTokenIssuer, vous devez ajouter l’approbation servant à signer les jetons oAuth à la liste des autorités racines approuvées dans SharePoint. Là encore, vous pouvez le faire de deux manières : si vous créez votre approbation par l’intermédiaire du point de terminaison de métadonnées, vous pouvez établir l’approbation comme suit :
New-SPTrustedRootAuthority -Name BATTERIE_A -MetadataEndPoint https://BATTERIE_A/_layouts/15/metadata/json/1/rootcertificate
D’une autre manière, vous pouvez l’ajouter à la liste des autorités racines approuvées exactement comme dans SharePoint 2010 :
$root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\sts.cer")
New-SPTrustedRootAuthority -Name "Certificat d’autorité de certification racine de signature de jeton" -Certificate $root
Du point de vue de l’approbation, vous en avez terminé à ce stade : votre approbation est établie et vous pouvez désormais créer de nouveaux principaux d’application en vous y référant. Son mode d’utilisation dépend de l’application elle-même ; dans le cas d’un index SharePoint distant, je poursuis le scénario pour le conclure.
Étape 4 : Création d’un principal d’application (exemple uniquement pour l’index SharePoint distant)
Ce processus se fait en deux étapes : obtenir un principal d’application, puis lui accorder des droits. Souvenez-vous d’après notre scénario que BATTERIE_B doit approuver les appels de BATTERIE_A, car elle va recevoir des requêtes pour l’index SharePoint distant. Donc pour mon principal d’application, je dois obtenir une référence à l’application Web dans BATTERIE_B que BATTERIE_A va utiliser. Une fois que j’ai cette référence, je peux accorder des droits à BATTERIE_A pour qu’elle l’utilise.
Pour obtenir une référence à un principal d’application, vous utilisez l’applet de commande de la manière suivante :
$p = Get-SPAppPrincipal -Site https://BATTERIE_B -NameIdentifier $i.NameId
IMPORTANT : Il convient de noter un élément qui probablement sera particulièrement courant pour la version SharePoint 2013 Bêta. Il se peut que vous obteniez d’étranges erreurs dans PowerShell lorsque vous essayez de récupérer SPAppPrincipal. J’ai constaté que si la mémoire disponible sur votre serveur descend en deçà de 5 %, alors tous les appels WCF échouent. Comme cette applet de commande PowerShell appelle un point de terminaison d’application de service, hébergé en tant que WCF, l’applet de commande Get-SPAppPrincipal échoue lorsque la mémoire est insuffisante. Vous pouvez consulter l’Observateur d’événements Windows dans le journal de l’application pour déterminer s’il s’agit de la cause de votre problème. Je l’ai constaté plusieurs fois jusqu’à présent, donc il est probable que d’autres en feront l’expérience.
Notez que comme je l’ai indiqué plus haut dans l’article, je finis par utiliser ma variable $i pour récupérer la valeur NameIdentifier du service STS dans BATTERIE_A. Maintenant que j’ai une référence au principal de l’application Web de BATTERIE_B, je peux lui accorder les droits suivants :
Set-SPAppPrincipalPermission -Site https://BATTERIE_B -AppPrincipal $p -Scope SiteSubscription -Right FullControl
Voilà. Vous disposez des options et méthodologies pour créer une approbation oAuth entre deux batteries de serveurs SharePoint. Je vais continuer d’évoquer régulièrement sur ce blog oAuth et ses utilisations et problèmes divers à connaître.
Cet article de blog est une traduction. Vous trouverez la version originale à l’adresse Setting Up an oAuth Trust Between Farms in SharePoint 2013