Autenticación de SAML federada con SharePoint 2010 y Azure Access Control Service, parte 1

Article
06/24/2011

Artículo original publicado el viernes, 6 de mayo de 2011

NOTA: Como de costumbre, el formato de este sitio es pésimo. Recomiendo descargar el documento de Word adjunto a esta entrada para una mejor lectura.

Recientemente he estado observando con interés Windows Azure Access Control Service (ACS) y considerando algunas de las distintas opciones de integración. Siempre hay mucho parloteo sobre la autenticación de notificaciones con SharePoint 2010 y sobre cómo integrar ADFS, Windows Live, Facebook, etc. ACS (también conocido como AppFabric ACS para los puristas de Azure y la gente de marketing) es bastante interesante porque incluye "conectores" para estos proveedores de identidades comunes. Al configurar un espacio de nombres de ACS (imagíneselo como una cuenta con conectores y opciones de configuración), dispone de conectividad simplificada a ADFS 2.0, Windows Live, Yahoo, Google y Facebook. El programador perezoso que hay en mí pensó que algo debía de estar ocurriendo allí, por lo que decidí echar un vistazo desde un par de ángulos distintos. En esta entrada, voy a describir el primero.

En este escenario, realmente solo quería establecer una confianza directa entre SharePoint 2010 y ACS. Quería poder usar cuentas de ADFS, Windows Live, Yahoo y Google para autenticarme y entrar a mi sitio de SharePoint. No incluí Facebook porque las redes sociales realmente no son lo mío (este blog es lo más cerca que llego), así que no tengo una cuenta en Facebook ni en Twitter, ya que realmente no me interesa compartir con frecuencia información inútil con el mundo en general ("Puffy acaba de tener tres gatitos. ¡Qué linda! "). NO voy a explicar cómo obtener una cuenta de Windows Azure, cómo crear un espacio de nombres de Access Control Service, cómo administrar ACS, etc. Debe de haber un montón de información por ahí de la gente de Windows Azure, por lo que no voy a tratar de volver a inventar nada.

Lo que voy a describir es el proceso de configuración de las diversas confianzas, los certificados y la configuración necesaria para hacer que todo esto funcione. Al final, incluiré algunas capturas de pantalla de inicios de sesión con las identidades de cada uno de esos proveedores. Estos son los pasos para conectarse:

Abrir la página Access Control Management (Administración de control de acceso)
1. Inicie sesión en el Portal de administración de Windows Azure. Haga clic en el menú Service Bus, Access Control and Caching (Bus de servicio, control de acceso y almacenamiento en caché) del panel izquierdo. Haga clic en Access Control (Control de acceso) en la parte superior del panel izquierdo (debajo de AppFabric), haga clic en el espacio de nombres del panel derecho y haga clic en el botón Access Control Service (Servicio de control de acceso) en la sección de administración de la cinta de opciones. Aparecerá la página Access Control Management.
Agregar un proveedor de identidades para AD FS
1. Haga clic en Identity providers (Proveedores de identidades) en el menú Trust relationships (Relaciones de confianza) del panel izquierdo.
2. Haga clic en el vínculo Add (Agregar).
3. El botón de radio de WS-Federation identity provider (proveedor de identidades de WS-Federation) debe estar seleccionado de manera predeterminada; actívelo si no lo está. Es lo que se usa para AD FS 2.0. Haga clic en el botón Next (Siguiente).
4. Rellene la sección Identity Provider Settings (configuración del proveedor de identidades).
  1. Rellene el nombre para mostrar, como, por ejemplo, "Mi servidor de AD FS".
  2. Para los metadatos de WS-Federation, si el servidor de AD FS está expuesto en Internet, simplemente colóquelo en la dirección URL para el extremo de metadatos de federación. De manera predeterminada es https://suServidorAdfs.com/FederationMetadata/2007-06/FederationMetadata.xml. Si el servidor de AD FS no está expuesto en Internet, abra la dirección URL en el extremo del explorador local. Vaya al explorador y guarde la página en el sistema local de archivos como archivo XML. A continuación, en la configuración del proveedor de identidades en ACS, haga clic en el botón de radio situado junto al cuadro de edición File (Archivo) y use el botón Browse (Examinar) para buscar el archivo XML de los metadatos de federación que acaba de guardar.

Eso es prácticamente todo lo que debe hacer para crear un proveedor de identidades en ACS.

3. Agregar un usuario de confianza para SharePoint

1. Ahora necesita agregar SharePoint como usuario de confianza de ACS, al igual que cuando se configuran SharePoint y AD FS juntos. Empiece haciendo clic en el vínculo Relying party applications (Aplicaciones de usuarios de confianza) en el menú Trust relationships (Relaciones de confianza) del panel izquierdo.
2. Haga clic en el vínculo Add (Agregar).
3. Rellene la sección Relying Party Application Settings (Configuración de la aplicación de usuario de confianza).
  1. Escriba un nombre para mostrar, como "Sharepoint 2010".
  2. Use el modo predeterminado para escribir la configuración manualmente.
  3. En el cuadro de edición Realm (Dominio kerberos) escriba un dominio kerberos y guárdelo porque lo volverá a usar al crear SPTrustedIdentityTokenIssuer en SharePoint. Para este ejemplo, supongamos que el dominio kerberos es “urn:sharepoint:acs”.
  4. Para la dirección URL de retorno, use el mismo formato que usa al configurar SharePoint como usuario de confianza en AD FS: https://nombreDelSitio/_trust/.
  5. La lista desplegable de formato de token debe ser SAML 1.1
  6. Puede establecer la duración del token (segundos) como desee. De manera predeterminada, es de 10 minutos. Yo establecí la mía en 3.600, es decir, una hora.
4. Rellene la sección Authentication Settings (Configuración de autenticación).
  1. Compruebe todos los cuadros debajo de Identity providers (proveedores de identidad); deben mostrar el proveedor de identidades de AD FS que se creó en el paso anterior.
  2. En Rule groups (Grupos de reglas), deje activado el valor predeterminado, es decir, Create new rule group (Crear nuevo grupo de reglas).
5. En Token Signing Settings (Configuración de firma de tokens), puede dejar seleccionada la opción predeterminada, que es Use service namespace certificate (Usar el certificado del espacio de nombres del servicio) (estándar).
6. Haga clic en el botón Save (Guardar) para guardar los cambios y crear el usuario de confianza.

4. Crear las reglas para el usuario de confianza

1. Aquí doy por sentado que no ha creado antes un conjunto de reglas en ACS, por lo que vamos a crear un nuevo grupo de estas. Si tuviera un grupo que deseara volver a usar, en el paso anterior simplemente tendría que haber puesto una marca junto a los grupos que desea usar con el usuario de confianza en lugar de aceptar el valor predeterminado de crear nuevo grupo de reglas. Pero como vamos a crear uno nuevo, haga clic en el vínculo Rule groups (Grupos de reglas) en el menú Trust relationships (Relaciones de confianza) del panel izquierdo.
2. Debe ver un grupo de reglas que tiene un nombre como "Grupo de reglas predeterminado para el nombre que tenga el usuario de confianza". Haga clic en ese vínculo para ese nombre de grupo de reglas.
3. Lo más fácil en este momento es simplemente hacer clic en el vínculo Generate (Generar). Se creará automáticamente un conjunto de reglas que básicamente enumera todas las notificaciones que se obtendrán de cada proveedor de identidades y después se creará una regla para cada uno que pase por ese valor de notificación con el mismo tipo de notificación en el usuario de confianza.
4. En la página de generación de reglas, active la casilla de verificación junto a cada proveedor de identidades y haga clic en el botón Generate (Generar). Se crean las reglas, tal como describí anteriormente. Cuando haya finalizado, se le redirigirá a la página Edit Rule Group (Edición de grupos de reglas), donde verá todas las reglas enumeradas. En muchos casos esto será suficiente, pero hay una anomalía aquí que debemos tener en cuenta. En SharePoint vamos a usar la dirección de correo electrónico como notificación de identidad. Irónicamente, todos los proveedores de identidades envían la dirección de correo electrónico (y tienen reglas creadas para ello), excepto Windows Live. Así que, por ahora, en este ejemplo voy a falsificar la parte de Windows Live. Con esto quiero decir que voy a tomar la única notificación que proporciona (nameidentifier) y voy a crear una regla que la devuelva, pero la va a devolver como notificación de correo electrónico. Este no es el momento de odiar a Steve, se trata simplemente de una forma para hacer que este entorno de demostración se ejecute con la menor cantidad de elementos móviles (y ya hay varios). Ahora agregaremos esta regla final.
5. Haga clic en el vínculo Add (Agregar).
6. En la lista desplegable Identity Provider (Proveedor de identidades), seleccione Windows Live I.
7. En la sección Input claim type (Tipo de notificación de entrada), haga clic en el botón de radio junto a Select type (Seleccionar tipo). Solo hay un tipo de notificación compatible con Windows Live ID, por lo que ya está seleccionado (nameidentifier).
8. Desplácese hacia abajo hasta la sección Output claim type (Tipo de notificación de salida) y haga clic en el botón de radio junto a Select type (Seleccionar tipo).
9. En la lista desplegable, busque https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress y selecciónelo.
10. Escriba una descripción si así lo desea y, a continuación, haga clic en el botón Save (Guardar) para guardar los cambios y crear la regla.
11. Se le redirigirá a la página Edit Rule Group (Edición de grupos de reglas). A continuación haga clic en el botón Save (Guardar) para guardar todos los cambios. Con esto se terminó la configuración de ACS, pero no cierre el explorador todavía porque necesitará obtener información adicional desde ahí cuando cree y configure los demás componentes.

5. Crear un usuario de confianza para ACS en AD FS

1. Mientras que AD FS es un proveedor de identidades para ACS, ACS es un usuario de confianza en AD FS. Esto significa que necesitamos configurar un usuario de confianza en AD FS de modo que cuando ACS redirija una solicitud de autenticación a ADFS, se establezca una confianza que permita que AD FS responda. Para empezar, vaya al servidor de AD FS y abra la consola de administración de AD FS 2.0.
2. Vaya a AD FS 2.0, a Trust Relationships (Relaciones de confianza), al nodo Relying Party (Confianza de usuario de confianza) y haga clic en el vínculo Add Relying Party (Agregar confianza de usuario de confianza) en el panel derecho.
3. Haga clic en el botón Start (Inicio) para iniciar el asistente.
4. Use la opción predeterminada para importar datos acerca del usuario de confianza publicado en línea. La dirección URL que debe usar está en el portal de administración de ACS. Vuelva al explorador que tiene el portal abierto y haga clic en el vínculo Application Integration (Integración de aplicaciones) en el menú Trust relationships (Relaciones de confianza) del panel izquierdo.
5. Copie la dirección URL que se muestra para los metadatos de WS-Federation y péguela en el cuadro de edición Federation metadata address (host name or URL) (Dirección de metadatos de federación; nombre de host o dirección URL) del asistente para AD FS y, a continuación, haga clic en el botón Next (Siguiente).
6. Escriba un nombre para mostrar y, opcionalmente, algunas notas y, a continuación, haga clic en el botón Next (Siguiente).
7. Deje la opción predeterminada para permitir que todos los usuarios tengan acceso al usuario de confianza y haga clic en el botón Next (Siguiente).
8. Haga clic en el botón Next (Siguiente) para que se cree el usuario de confianza.
9. Una vez creado el usuario de confianza, abra el editor de reglas en AD FS para crear nuevas reglas y pasar valores de notificación a ACS.
10. Con la ficha Issuance Transform Rules (Reglas de transformación de emisión) seleccionada, haga clic en el botón Add Rule (Agregar regla).
11. Deje seleccionada la plantilla predeterminada Send LDAP Attributes as Claims (Enviar atributos de LDAP como notificaciones) y haga clic en el botón Next (Siguiente).
12. Rellene el resto de los detalles de reglas:
  1. Escriba un nombre de regla de notificación.
  2. En la lista desplegable Attribute store (Almacén de atributos), seleccione Active Directory.
  3. En la sección Mapping of LDAP attributes (Asignación de atributos de LDAP), asigne:
    1. Direcciones de correo electrónico de atributo de LDAP a la dirección de correo electrónico del tipo de notificación saliente
    2. Grupos de tokens de atributo de LDAP (nombres no completos de rol de tipo de notificación saliente)
  4. Haga clic en el botón Finish (Finalizar) para guardar la regla. La configuración de AD FS ya está completa.

6. Configurar la confianza de SharePoint con ACS

1. Este es un proceso de varios pasos que comienza con la obtención del certificado de firma de tokens en ACS. Afortunadamente, el certificado viene incluido en el archivo FederationMetadata.xml, por lo que vamos a recuperarlo de allí y guardarlo localmente en el servidor de SharePoint. En el servidor de SharePoint, abra un explorador y abra la página de administración de control de acceso, tal como se describió anteriormente.
2. Haga clic en el vínculo de integración de aplicaciones en el menú Trust relationships (Relaciones de confianza) del panel izquierdo, copie la dirección URL que se muestra para los metadatos de WS-Federation y péguela en su explorador. El archivo FederationMetadata.xml de ACS se mostrará en el explorador.
3. Busque la sección que tiene el aspecto siguiente (es más o menos la segunda sección principal desde la parte superior de la página):

<X509Certificate>MIIDEDCCAfiblahblahblah</X509Certificate>

</X509Data>

Copie los datos del elemento X509Certificate y péguelos en el Bloc de notas. Guárdelos con una extensión de archivo .CER (la codificación debe ser ANSI). En el contexto de esta entrada de blog vamos a asumir que el archivo se denomina C:\AcsTokenSigning.cer. Este es el certificado de firma de tokens de ACS.

1. Agregue el certificado de firma de tokens de ACS a la lista de entidades de certificación raíz de confianza en SharePoint. Puede hacerlo tal como se describe en https://blogs.technet.com/b/speschka/archive/2010/07/07/managing-trusted-root-authorities-for-claims-authentication-in-sharepoint-2010-central-admin.aspx o puede agregarlo con PowerShell de la siguiente forma:

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\AcsTokenSigning.cer")

New-SPTrustedRootAuthority -Name "ACS Token Signing" -Certificate $cert

1. El siguiente paso es crear el nuevo SPTrustedIdentityTokenIssuer. He explicado esto en diversos lugares; puede usar https://blogs.technet.com/b/speschka/archive/2010/07/30/configuring-sharepoint-2010-and-adfs-v2-end-to-end.aspx como punto de partida (simplemente desplácese hacia abajo a la información que viene DESPUÉS de configurar AD FS).Deberá tener en cuenta ciertos puntos:
  1. Name y nameidentifier son tipos de notificación reservados en SharePoint, por lo que aunque nameidentifier sea la única notificación común en los proveedores de identidades estándar en ACS, no es una opción para la notificación de identidad. En su lugar, recomiendo por ahora volver a la dirección de correo electrónico y agregar las reglas adecuadas en ACS, tal como lo describí anteriormente.
  2. El parámetro SignInUrl para el nuevo New-SPTrustedIdentityTokenIssuer debe señalar a la instancia de ACS. Por ejemplo, https://miESpacioDeNombresAcs.accesscontrol.windows.net:443/v2/wsfederation. Para encontrarlo, puede buscar el usuario de confianza configurado en AD FS para ACS. Abra el cuadro de diálogo Relying Party Properties (Propiedades del usuario de confianza), haga clic en la pestaña Endpoints (Extremos) y use la dirección URL que se muestra para el extremo pasivo de WS-Federation para el enlace POST (debe ser el único que está allí).
2. El último paso es crear una aplicación web, configurarla para usar autenticación de notificaciones y el SPTrustedIdentityTokenIssuer creado para ACS, y, por último, crear una colección de sitios en la aplicación web y empezar a probar.

En este momento debe estar listo para visitar el sitio y probarlo. Recuerde que necesitará configurar el administrador de la colección de sitios para que sea una de las direcciones de correo electrónico que uno de los proveedores de identidades devolverá para poder iniciar sesión en el sitio. Una vez allí, puede agregar direcciones de correo electrónico o las notificaciones de rol de los proveedores a los grupos de SharePoint tal como normalmente esperaría poder hacer.

La única advertencia que debe recordar una vez más, por ahora, es Windows Live ID. Como mencioné anteriormente en esta entrada, realmente no hay una dirección de correo electrónico válida para Windows Live, por lo que tendrá que agregar lo que se llama PUID al grupo de SharePoint. Para realizar pruebas, la forma más sencilla de conseguirlo es iniciar sesión mediante Windows Live ID y, a continuación, llegar a la página de SharePoint que indica que se ha iniciado sesión como "foo" y que el acceso está denegado. Desde allí puede copiar el PUID, iniciar sesión como usuario administrador, agregar el PUID a un grupo de SharePoint y debería poder continuar. Ni siquiera he mirado el tipo de opciones de directorio, si las hay, que están disponibles para Windows Live ID (supongo que probablemente no hay ninguna). Pero es un punto de partida para que podamos hacer avanzar esta prueba de concepto. Ahora que lo hemos hecho, este es el aspecto que tiene el inicio de sesión en mi sitio al usar cada uno de estos proveedores de identidades:

Página de inicio de sesión

AD FS

Google

Yahoo

Windows Live ID

Esta entrada de blog es una traducción. Puede consultar el artículo original en Federated SAML Authentication with SharePoint 2010 and Azure Access Control Service Part 1

Autenticación de SAML federada con SharePoint 2010 y Azure Access Control Service, parte 1

Additional resources