Introducción
Aprovechando la aparición del número 8 de la revista CompartiMOSS he pensado publicar la traducción al español de un artículo que recientemente publiqué en el blog de MVP Award Program y que sirve para complementar lo que aparece en la revista ya que, debido a lo extenso que hubiera resultado, no pude detallar como me hubiera gustado.
Antes de explicar cómo conseguir autenticar usuarios de SharePoint 2010 con un sistema externo mediante Azure ACS v2 es conveniente explicar los motivos que nos pueden empujar a querer hacerlo, así que voy a intentar dar mis razones en esta introducción con el lenguaje menos técnico posible.
¿Qué opciones tengo?
Por defecto, SharePoint 2010 permite autenticar a los usuarios mediante Directorio Activo, pero además de esto podemos optar por un repositorio de usuarios diferente mantenido por nosotros mismos como, por ejemplo, una base de datos SQL Server o incluso un sistema totalmente ajeno a nosotros como Windows Live ID, Google o Facebook. En general, la primera opción se aconseja para entornos corporativos por la alta integración que obtendríamos con las herramientas de Office mientras que las otras opciones se suelen recomendar para escenarios públicos. No es una fórmula matemática, pero funciona en la mayoría de casos
¿Por qué utilizar un sistema externo?
Si nos encontramos en una situación donde Directorio Activo no es una opción podemos optar por implementar nuestro propio repositorio de datos o utilizar uno ajeno. Las principales razones que nos empujarían a la segunda opción son:
- No tenemos que preocuparnos por mantener la información en nuestro propio sistema ni de asegurar su integridad.
- No es necesario implementar mecanismos relacionados con la gestión de usuarios como, por ejemplo, registro de usuario o recuperación de contraseña.
- Nuestros usuarios no tendrán que mantener otro conjunto de credenciales adicional a los que ya tenían.
Si tenemos claro que queremos utilizar un sistema externo la siguiente pregunta a realizarnos sería si necesitamos utilizar un único sistema o queremos federar las identidades de varios de ellos. Si nos encontramos en el segundo caso aparecen dos alternativas posibles: ADFS 2.0 o Azure ACS v2, que podría ser traducido como ADFS 2.0 en la nube.
¿Por qué utilizar Azure ACS v2 en lugar de ADFS 2.0?
Siempre que comparamos una plataforma instalada on-premises con la misma plataforma utilizada como servicio aparecen los mismos argumentos:
- Escalabilidad
- Mantenibilidad
- Coste (TCO)
- Rendimiento
- Etc.
Cada una de las dos alternativas tendrá unas valoraciones diferentes para cada argumento. Si ponemos en una balanza todos estos argumentos con el peso que demos a cada uno de ellos tendremos la respuesta a la pregunta planteada anteriormente.
Manos a la obra
Si después de plantearte todas las preguntas anteriores has llegado a la conclusión de que quieres utilizar varios sistemas externos y quieres utilizar los servicios de autenticación que proporciona Azure, te interesa seguir leyendo para saber cómo configurar SharePoint 2010 para poner todo esto en marcha.
Antes de comenzar a configurar nada conviene plantearnos lo que queremos implementar. Para el ejemplo que nos ocupa yo he pensado crear un portal público en la url https://www.contoso-acsv2.com con acceso anónimo permitido y con un área privada a la que únicamente se puede acceder con unas credenciales válidas de Windows Live ID o de Google. Con esta información podemos comenzar a preparar nuestra granja de SharePoint 2010 para dar soporte a este escenario.
Doy por sentado que aquellos que estáis leyendo este artículo tenéis los conocimientos necesarios para realizar las tareas de alto nivel que voy a especificar a continuación pero, si no es así, no dudéis en enviarme vuestras preguntas o comentarios. En cualquier caso, ya os adelanto que al final de este artículo os dejaré un enlace donde podréis acceder a un entorno totalmente preparado y que podréis utilizar a vuestra conveniencia.
1. Creación de una aplicación web para acceso interno con la siguientes características
- Autenticación basada en claims (IMPORTANTE!)
- SSL no habilitado
- Autenticación NTLM
- Acceso anónimo no habilitado
2. Creación de una colección de sitios a partir de la plantilla de sitio de publicación. Antes de continuar con el artículo comprobar que podemos navegar a la colección de sitios que acabamos de crear. Observaréis, en la parte superior de derecha, que el usuario con el que os habéis conectado es un usuario de Directorio Activo.
Antes de proceder con la siguiente tarea necesitaremos crear un certificado digital para firmar los tokens. Aprovechando el hecho que también necesitaremos un certificado para el sitio que publicaremos por https y teniendo en cuenta que lo que vamos a hacer es únicamente para pruebas, procederemos de la siguiente manera:
1. En el servidor de SharePoint, abrir una ventana de comandos y situarse en la carpeta C:\Program Files\Microsoft Office Servers\14.0\Tools.
2. Ejecutar el siguiente comando: MakeCert.exe -r -pe -n "CN=www.contoso-acsv2.com" -sky exchange -ss my
3. Abrir con la consola de administración ejecutando el comando mmc.exe y añadir el snap-in de certificados del usuario actual.
4. Localizar en la carpeta personal el certificado para www.contoso-acsv2.com y exportarlo al disco duro. Aprovechad este momento para exportarlo con (.PFX), y sin clave privada asociada (.CER) ya que necesitaremos ambos en diferentes partes de este artículo.
Nota: en un escenario real deberíais utilizar certificados diferentes para firmar tokens y para el servidor web. Además, no se recomienda utilizar certificados auto-generados para entornos en producción.
Una vez creada la colección de sitios con la que trabajaremos y generado el certificado digital, lo siguiente que tendremos que hacer es crear un espacio de nombres en Azure ACS v2 que identifique nuestra aplicación y, para ello, deberemos seguir los siguientes pasos:
1. Acceder al portal de AppFabricLabs (https://portal.appfabriclabs.com)
Nota: este artículo utilizará la versión de laboratorio de Azure ACS v2, que es gratuíta pero que no puede utilizarse en entornos reales en producción. La versión comercial de Azure ACS v2 está disponible a través del portal de Windows Azure.
2. Localizar y pulsar, en la parte inferior izquierda de la pantalla, el enlace Service Bus, Access Control & Caching.
3. Seleccionar Access Control en el menú de navegación de la izquierda y pulsar el botón New Namespace en la ribbon.
4. Rellenar el formulario indicando un espacio de nombres que esté disponible y una región (de momento únicamente podemos seleccionar Estados Unidos)
5. Pulsar el botón Create Namespace y esperar a que el servicio pase a estado activado.
Una vez creado y activado el espacio de nombres, la siguiente tarea consiste en configurarlo para que de soporte a nuestras necesidades. Para ello procederemos de la siguiente manera:
1. Seleccionar el espacio de nombres y pulsar el botón Access Control Service en la ribbon. Esto nos llevará al portal de administración de nuestro espacio de nombres.
2. Pulsar el enlace Identity providers en el menú de navegación de la izquierda. Veréis que, por defecto, el sistema nos va a permitir utilizar Windows Live ID como sistema de autenticación.
3. En este artículo queremos demostrar el uso de más de un sistema de autenticación y, por lo tanto, pulsaremos el enlace Add y añadiremos Google a la lista de proveedores autorizados. Vosotros, si lo preferís, podéis añadir Facebook o Yahoo.
4. La siguiente pantalla os permitirá indicar un texto y una imagen que se utilizará en la pantalla de inicio de sesión a la hora de seleccionar el proveedor que queremos utilizar para ingresar en el sistema. Podéis dejar los valores por defecto y pulsar el botón Save.
5. Pulsar el enlace Relying Party Applications en el menú de navegación de la izquierda y pulsar el botón Add que aparece en la siguiente pantalla.
6. Rellenar el formulario con los siguientes valores y pulsar el botón save.
- Name: contoso-acsv2.com
- Realm: https://www.contoso-acsv2.com/
- Return URL: https://www.contoso-acsv2.com/_trust/
- Token format: SAML 1.1
- Token lifetime: 600 secs
- Google: opción marcada
- Live ID: opción marcada
- Create new rule group: opción marcada
- Token signing: Use a dedicated certificate (poner aquí los valores que habéis obtenido a la hora de exportar el certificado digital con clave privada)
7. Pulsar el enlace Rule groups en el menú de navegación de la izquierda y, en la lista que aparece, pulsar el enlace Default rule for contoso-acsv2.com. Una vez allí, pulsar el enlace Generate, dejar marcadas las opciones Windows Live ID y Google y pulsar el botón Generate.
8. La siguiente pantalla nos mostrará los claims que vamos a recibir de aquellos sistemas con los que nos integremos. En nuestro caso vamos a hacer un pequeño cambio. Debido a que Live ID no nos envía el email del usuario y nosotros queremos utilizar este claim más adelante añadimos un nuevo claim con los siguientes valores:
- Identity Provider: Windows Live ID
- Input Claim Type: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
- Output Claim type: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
Teniendo configurado nuestro espacio de nombres en Azure ACS v2 y con el certificado preparado podemos proceder a configurar nuestro proveedor autorizado de autenticación en SharePoint 2010. Para ello seguiremos los siguientes pasos:
1. Copiar el texto a continuación y guardarlo como fichero con extensión ps1 en la carpeta donde anteriormente exportamos el certificado digital.
$realm = "https://www.contoso-acsv2.com"
$signinurl = "https://example-acsv2.accesscontrol.appfabriclabs.com/v2/wsfederation"
$certloc = (Get-ChildItem . -Recurse -include www.contoso-acsv2.com.cer).fullname
$rootcert = Get-PfxCertificate $certloc
New-SPTrustedRootAuthority "Azure ACSv2" -Certificate $rootcert
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certloc)
$map1 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "Email" -SameAsIncoming
New-SPTrustedIdentityTokenIssuer -Name "Azure ACSv2" -Description "Windows Azure ACS v2" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType
2. Abrir la Consola de Administración de SharePoint 2010 y ejecutar el fichero previamente guardado.
Ya estamos en disposición de continuar nuestro trabajo en la Administración Central de SharePoint. Nos faltaría únicamente extender la aplicación web que creamos al inicio de este artículo usando, para ello, las siguientes configuraciones.
- Puerto: 443
- Host header: www.contoso-acsv2.com
- Acceso anónimo: habilitado
- SSL: habilitado
- Proveedor de autenticación: Azure ACSv2
Antes de poder acceder al sitio web que acabamos de crear necesitaremos realizar algunas tareas relacionadas con certificados.
1. Abrir la consola de Internet Information Services, seleccionar el nombre de nuestro servidor en la sección de la izquierda y abrir la característica Server Certificates en la ventana principal.
2. Importar el certificado con clave privada (.PFX) mediante el menú de acciones de la derecha.
3. Pulsar con el botón derecho del ratón sobre el sitio web que hemos creado para acceder mediante SSL y seleccionar Edit Bindings.
4. Editar el enlace que se ha creado por defecto y asignarle el certificado que previamente hemos importado.
Una vez hecho esto ya podréis navegar a la url https://www.contoso-acsv2.com y, como veréis, el sistema os redigirá a una pantalla donde os aparecerá la lista de proveedores de identidad que habéis configurado en Azure ACS v2 (en nuestro ejemplo Windows Live ID y Google). Pero si intentáis acceder con vuestras credenciales recibiréis un error. Aún es necesario un último paso que consiste en acceder de nuevo a la gestión de certificados del servidor de SharePoint y copiar el certificado generado para www.contoso-acsv2.com que encontraremos en la carpeta Personal a las siguientes tres carpetas:
- SharePoint
- Trusted People
- Trusted Root Certification Authorities
En estos momentos ya podéis acceder al sitio pero, obviamente, recibiréis un error de acceso denegado. A modo de demostración daremos acceso de lectura total a cualquier usuario que se identifique con unas credenciales válidas. Para ello seguimos los siguientes pasos:
1. Desde la administración de aplicaciones web en la Administración Central de SharePoint seleccionamos la aplicación web que creamos al inicio de este artículo.
2. Pulsamos en la ribbon el botón User Policy.
3. Seleccionamos ‘All Users [Azure ACSv2]’ y le asignamos permisos de lectura total.
De cara a obtener el entorno dal cual lo habíamos planteado al inicio será necesario habilitar el acceso anónimo en la colección de sitios y crear un subsitio con permisos específicos en el cual no esté habilitado el acceso anónimo. Al volver a ser una tarea de alto nivel que no tiene ninguna relación con Azure ACS v2 no detallaré los pasos pero, de nuevo, si tenéis algún tipo de duda en este punto no dudéis en dejarme un comentario.
Finalmente ya tenemos nuestro entorno totalmente preparado. A partir de este momento, cada vez que accedamos a la url https://www.contoso-acsv2.com el sistema nos permitirá indicar unas credenciales válidas en Windows Live ID o en Google para acceder al sistema. Evidentemente esto es únicamente el punto de partida para comenzar a trabajar con Windows Azure ACS v2 ya que se abre un amplio abanico de posibilidades. Si queréis comenzar a explorar este mundo y no queréis perder tiempo preparando este entorno, he publicado un permalink con todo lo que he explicado en este artículo totalmente configurado y que podéis utilizar a vuestra conveniencia.
0 comentarios:
Publicar un comentario