Usar notificaciones de SAML en SharePoint 2010 con sitios con encabezado host

  • Article

Artículo original publicado el domingo, 19 de junio de 2011

Alguien me hizo una pregunta interesante el otro día, sobre la posibilidad de usar o no notificaciones de SAML con sitios con encabezado host en SharePoint 2010. Lo primero que pensé fue que sí, pero quería profundizar un poco más en el tema para investigar. La respuesta breve para todo esto es que sí, pero no es tan fácil como esperaba. Para mi pequeño ejemplo, creé una aplicación web en https://hh.vbtoys.com y dos sitios con encabezado host: https://ash.vbtoys.com y https://josh.vbtoys.com. Si bien esto no entra exactamente en el modelo clásico de sitios con encabezado host (con el significado de URL mnemónicas), recuerde que una de las restricciones con notificaciones de SAML y SharePoint es que los sitios deben usar SSL. Entonces, en lugar de tener que lidiar con la creación de un certificado SSL con Nombres alternativos de sujeto (SAN), decidí simplificar la vida un poco para poder usar un certificado comodín. Es suficiente para probar si funciona y qué configuración hace falta, pero espero que también sea un buen recordatorio de algo en que pensar si desea usar sitios con encabezado host y autenticación de SAML.

Entonces hice una prueba sencilla primero para probar la situación utópica en la que pudiera realizar solo un cambio de configuración y hacer que todos los sitios con encabezado host simplemente funcionasen. En ese caso, hice dos cosas:

  1. Creé un nuevo usuario de confianza en ADFS que usaba https://hh.vbtoys.com/_trust/ como extremo WS Fed y un URN de urn:sharepoint:hh.
  2. Agregué un dominio kerberos de proveedor a mi SPTrustedIdentityTokenIssuer existente de esta manera:

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

Así que probé llegar a https://hh.vbtoys.com primero y todo funcionó bien: entré al sitio sin problemas. Luego en la prueba real de la situación utópica llegué a https://ash.vbtoys.com. Lamentablemente, no resultó ser utópico. Me redirigió a un SPTrustedIdentityTokenIssuer completamente distinto, así que supongo que SharePoint hizo una búsqueda en su lista de dominios kerberos de proveedor y no pudo encontrar nada para https://ash.vbtoys.com y por eso simplemente tomó el primer SPTrustedIdentityTokenIssuer de mi lista.

Pero no todo estaba perdido... como posiblemente se imagine en este punto, pude hacer funcionar mis dos sitios con encabezado host, pero tuve que crear lo siguiente:

  1. Un nuevo usuario de confianza en ADFS para cada colección de sitios con encabezado host
  2. Un nuevo dominio kerberos de proveedor para cada colección de sitios con encabezado host, y agregarlo a mi SPTrustedIdentityTokenIssuer. Usé exactamente el mismo PowerShell que mostré más arriba, solo le modifiqué la URL y el URN para cada uno. Por ejemplo, así es como agregué compatibilidad con 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()

Lo importante de esto es que agregando un nuevo usuario de confianza y un nuevo dominio kerberos de proveedor (URI y URN), para cada colección de sitios con encabezado host, pude iniciar sesión en cada sitio mediante autenticación de SAML.

Esta entrada de blog es una traducción. Puede consultar el artículo original en Using SAML Claims in SharePoint 2010 with Host Header Sites