En una entrada anterior os comencé a hablar del concepto notificación, o claim, y del sistema de autenticación basado en notificaciones. En esta segunda entrada de la serie os voy a explicar cómo configurar una aplicación web de SharePoint 2010 para hacer uso de estas capacidades. La información la obtuve de aquí, pero me encontré con algún que otro problema, así que en esta entrada os explico paso a paso todas las acciones que realicé.
Para empezar, abriremos la Administración Central de SharePoint y, dentro de la sección Administración de aplicaciones seleccionaremos la opción Administrar aplicaciones web.
Una vez allí, crearemos una nueva aplicación web desde la cinta o ribbon.
En la ventana modal que nos aparece seleccionaremos Autenticación basada en notificaciones.
En la misma ventana veremos que, por defecto, la autenticación de Windows está habilitada. Esto lo mantendremos igual pero también habilitaremos la autenticación basada en formularios, tal y como se indica en la imagen. Notad que he usado los nombres LDAPMembershipProvider y LDAPRoleProvider para los proveedores de suscripciones y de roles respectivamente. Necesitaremos estos dos nombres más adelante. Podéis modificar el resto de las propiedades (puerto, encabezado de host, nombre de la base de datos, etc.) según vuestras necesidades. Una vez estéis listos, aceptad el formulario para que se cree la aplicación web. No creéis todavía la colección de sitios.
A continuación necesitamos hacer ciertos cambios a algunos ficheros de configuración web.config. Lo primero que haremos es identificar estos ficheros:
Fichero 1 (el web.config de la aplicación web que acabamos de crear): lo podemos encontrar, por defecto, en la carpeta c:\inetpub\wwwroot\wss\VirtualDirectories\X, donde X es una combinación entre el número de puerto y el encabezado de host que hemos escogido en el paso anterior. Si habéis cambiado la carpeta por defecto de IIS, siempre podréis utilizar el siguiente método para abrir la carpeta contenedora de vuestra aplicación web: accedéis a la administración de IIS, pulsáis con el botón derecho del ratón sobre vuestra aplicación web y seleccionáis explorar.
Fichero 2 (el web.config de la Administración Central de SharePoint): para encontrarlo podemos utilizar el método anterior sobre la aplicación web SharePoint Central Administration v4.
Fichero 3 (el web.config del Security Token Service (STS)): para encontarlo podéis utilizar el método anterior sobre el directorio virtual SecurityTokenServiceApplication dentro de la aplicación web SharePoint Web Services.
Muy bien, una vez tengamos localizados nuestros tres ficheros, y atención porque los cambios a realizar en cada uno de estos son diferentes, procederemos a su configuración.
En el fichero 1 (nuestra aplicación web), buscaremos la sección:
<membership defaultProvider="i">
<providers>
<add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
</providers>
</membership>
y la cambiaremos por:
<membership defaultProvider="i">
<providers>
<add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
<add name="LDAPMembershipProvider"
type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
server="msdn.2010rc.local"
port="389"
useSSL="false"
userDNAttribute="distinguishedName"
userNameAttribute="sAMAccountName"
userContainer="CN=Users,DC=2010rc,DC=local"
userObjectClass="person"
userFilter="(&(ObjectClass=person))"
scope="Subtree"
otherRequiredUserAttributes="sn,givenname,cn" />
</providers>
</membership>
Notad que hay algunos elementos que deberéis modificar en vuestro entorno. Lo primero, como nombre del proveedor he utilizado LDAPMembershipProvider, que es el nombre que he especificado a la hora de crear la aplicación web. Además, el FQDN de la granja donde estoy trabajando es 2010rc.local y el nombre del servidor de dominio se llama MSDN, así que todas las propiedades que hacen referencia a la cadena de conexión LDAP apuntarán a msdn.2010rc.local. Prestad especial atención al atributo userContainer que cambia un poco respecto a lo que encontramos en el artículo de Technet. Todos estos cambios deberán tenerse en cuenta en todas las modificaciones que hagamos en pasos sucesivos. Tenedlo en cuenta si copias el contenido directamente de esta página.
Además de este cambio deberemos buscar la siguiente sección:
<roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false">
<providers>
<add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
</providers>
</roleManager>
y cambiarla por:
<roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false">
<providers>
<add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
<add name="LDAPRoleProvider"
type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
server="msdn.2010rc.local"
port="389"
useSSL="false"
groupContainer="DC=2010rc,DC=local"
groupNameAttribute="cn"
groupNameAlternateSearchAttribute="samAccountName"
groupMemberAttribute="member"
userNameAttribute="sAMAccountName"
dnAttribute="distinguishedName"
groupFilter="(&(ObjectClass=group))"
userFilter="(&(ObjectClass=person))"
scope="Subtree" />
</providers>
</roleManager>
En el fichero 2 (Adminitración Central), buscaremos la siguiente sección (*):
<roleManager>
<providers>
</providers>
</roleManager>
<membership>
<providers>
</providers>
</membership>
y cambiarla por lo siguiente:
<roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider" >
<providers>
<add name="LDAPRoleProvider"
type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
server="msdn.2010rc.local"
port="389"
useSSL="false"
groupContainer="DC=2010rc,DC=local"
groupNameAttribute="cn"
groupNameAlternateSearchAttribute="samAccountName"
groupMemberAttribute="member"
userNameAttribute="sAMAccountName"
dnAttribute="distinguishedName"
groupFilter="((ObjectClass=group)"
userFilter="((ObjectClass=person)"
scope="Subtree" />
</providers>
</roleManager>
<membership defaultProvider="AspNetSqlMembershipProvider">
<providers>
<add name="LDAPMembershipProvider"
type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
server="msdn.2010rc.local"
port="389"
useSSL="false"
userDNAttribute="distinguishedName"
userNameAttribute="sAMAccountName"
userContainer="CN=Users,DC=2010rc,DC=local"
userObjectClass="person"
userFilter="(ObjectClass=person)"
scope="Subtree"
otherRequiredUserAttributes="sn,givenname,cn" />
</providers>
</membership>
(*) Nota: si no encontramos esta sección dentro del fichero podemos añadir directamente el código anterior justo antes de la linea </system.web>.
Finalmente, en el fichero 3 (STS), añadiremos dentro de la sección <configuration> la siguiente sección:
<system.web>
<membership>
<providers>
<add name="LDAPMembershipProvider"
type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
server="msdn.2010rc.local"
port="389"
useSSL="false"
userDNAttribute="distinguishedName"
userNameAttribute="sAMAccountName"
userContainer="CN=Users,DC=2010rc,DC=local"
userObjectClass="person"
userFilter="(&(ObjectClass=person))"
scope="Subtree"
otherRequiredUserAttributes="sn,givenname,cn" />
</providers>
</membership>
<roleManager enabled="true" >
<providers>
<add name="LDAPRoleProvider"
type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
server="msdn.2010rc.local"
port="389"
useSSL="false"
groupContainer="DC=2010rc,DC=local"
groupNameAttribute="cn"
groupNameAlternateSearchAttribute="samAccountName"
groupMemberAttribute="member"
userNameAttribute="sAMAccountName"
dnAttribute="distinguishedName"
groupFilter="(&(ObjectClass=group))"
userFilter="(&(ObjectClass=person))"
scope="Subtree" />
</providers>
</roleManager>
</system.web>
Una vez hecho esto ya estamos preparados para crear la colección de sitios. Accediendo a la Administración Central de SharePoint y seleccionando la opción Crear colecciones de sitios dentro de la sección Administración de aplicaciones.
Ahora llega el momento de explicaros por qué hemos decidido esperar a este momento para crear la colección de sitios. Si seleccionáis la aplicación web que acabamos de configurar e indicamos los datos básicos para nuestra colección de sitios (título, descripción, plantilla, etc.) veremos un cambio a la hora de seleccionar el administrador de la colección de sitios veremos una pantalla similar a la siguiente:
Cómo véis, sin hacer nada especial podemos seleccionar desde un mismo punto usuarios de los dos mecanismos de autenticación que tenemos configurados para nuestra aplicación web: Directorio Activo y FBA. Podemos aprovechar este momento para seleccionar un administrador principal y uno secundario, cada uno de ellos escogidos de un proveedor diferente. De esa manera podremos autenticarnos con los dos métodos desde el inicio. El apartado de administradores de la colección de sitios querará más o menos así:
A partir de este momento, cuando accedamos al portal que hemos creado nos aparecerá una ventana de inicio de sesión como la de la siguiente figura. Esta ventana, evidentemente, es totalmente personalizable. Podemos cambiar la apariencia gráfica o incluso podemos cambiar el comportamiento para permitir, por ejemplo, que los usuarios que accedan desde una IP interna se autentiquen directamente contra Directorio Activo mientras que el resto sean redirigidos a una página con el típico formulario de nombre de usuario y contraseña.
Una vez introduzcamos nuestra credenciales (sea cual sea la opción de autenticación que tomemos) accederemos a la colección de sitios que acabamos de crear, con las mismas credenciales puesto que estamos usando LDAP contra el mismo directorio activo para autenticarnos por formularios pero con unos atributos totalmente diferentes. Os recomiendo, para continuar, que pongáis en práctica un desarrollo que realicé para un artículo anterior para comprobar los atributos que tenemos en cada uno de los casos.
