Utilisation des revendications SAML dans SharePoint 2010 avec des sites à en-tête d’hôte

  • Article

Article d’origine publié le dimanche 19 juin 2011

L’autre jour, quelqu’un m’a posé une question intéressante : est-il possible d’utiliser des revendications SAML avec des sites à en-tête d’hôte dans SharePoint 2010 ? Ma première pensée a été que oui, mais j’ai voulu creuser un peu plus la question. La réponse est globalement oui, mais ce n’est pas aussi simple que je le pensais. Comme petit échantillon, j’ai créé une application Web à l’adresse https://hh.vbtoys.com et deux sites à en-tête d’hôte : https://ash.vbtoys.com et https://josh.vbtoys.com. Bien que cela ne corresponde pas totalement au modèle classique des sites à en-tête d’hôte (c.-à-d. URL de vanité), souvenez-vous que l’une des restrictions avec les revendications SAML et SharePoint est que les sites doivent utiliser SSL. Alors, plutôt que m’embêter à créer un certificat SSL avec SAN (Subject Alternate Names), j’ai décidé de me simplifier la vie et d’utiliser un certificat générique. Cela est suffisant pour prouver si ça fonctionne ou non et pour déterminer la configuration requise, mais c’est aussi une astuce à envisager si vous souhaitez utiliser des sites à en-tête d’hôte avec l’authentification SAML.

J’ai d’abord effectué un simple test pour essayer ce scénario utopique où je pourrais faire un seul changement de configuration avec tous les sites à en-tête d’hôte qui fonctionnent. Dans ce cas de figure, j’ai effectué les deux opérations suivantes :

  1. J’ai créé une nouvelle partie de confiance dans ADFS qui utilisait https://hh.vbtoys.com/_trust/ en tant que point de terminaison WS Fed et l’URN urn:sharepoint:hh.
  2. J’ai ajouté un domaine de fournisseur à mon SPTrustedIdentityTokenIssuer existant de la manière suivante :

$ap = Get-SPTrustedIdentityTokenIssuer -identity "ADFS IdP"
$uri = new-object System.Uri("https://hh.vbtoys.com")
$ap.ProviderRealms.Add($uri, "urn:sharepoint:hh")
$ap.Update()

J’ai tout d’abord essayé d’accéder à https://hh.vbtoys.com et j’ai accédé au site sans problème. Ensuite, lors du test réel du scénario utopique, j’ai tapé https://ash.vbtoys.com. Malheureusement, j’ai été redirigé vers un SPTrustedIdentityTokenIssuer entièrement différent ; j’en ai déduit que SharePoint faisait une recherche dans sa liste de domaines de fournisseur et ne trouvait rien pour https://ash.vbtoys.com, donc récupérait le premier SPTrustedIdentityTokenIssuer de ma liste.

Tous n’était pas perdu cependant... comme vous pouvez l’imaginer à ce stade, j’étais capable de faire fonctionner mes deux sites à en-tête d’hôte, mais je devais créer :

  1. Une nouvelle partie de confiance dans ADFS pour chaque collection de sites à en-tête d’hôte
  2. Un nouveau domaine de fournisseur pour chaque collection de sites à en-tête d’hôte, et l’ajouter à mon SPTrustedIdentityTokenIssuer. J’ai utilisé la commande PowerShell exactement comme ci-dessous, en modifiant simplement l’Url et l’Urn pour chacune. Par exemple, voici comment j’ai ajouté la prise en charge de https://ash.vbtoys.com :

$ap = Get-SPTrustedIdentityTokenIssuer -identity "ADFS IdP"
$uri = new-object System.Uri("https://ash.vbtoys.com")
$ap.ProviderRealms.Add($uri, "urn:sharepoint:ash")
$ap.Update()

En ajoutant une nouvelle partie de confiance et un nouveau domaine de fournisseur (Uri et Urn), pour chaque collection de sites à en-tête d’hôte, je pouvais me connecter à chaque site en utilisant l’authentification SAML.

Ce billet de blog a été traduit de l’anglais. Vous trouverez la version originale ici : Using SAML Claims in SharePoint 2010 with Host Header Sites