lunes, 2 de marzo de 2015

Sharepoint, FBA, Custom Identity Provider

Estos días he estado haciendo unas pruebas de concepto para ver el modo más sencillo controlar y personalizar el proceso de autenticación de usuarios en Sharepoint 2013.

¿Para que podría servirte la información que comparto en este artículo?

  • Imagina que dentro de la infraestructura de aplicaciones o servicios que trabajas tienes un IDP y quieres integrar Sharepoint como un servicio más dentro de la plataforma. El mismo ejemplo aplica si en vez de tener el membership en un IDP quieres que persista en una base de datos SQL o un archivo XML o …

  • Quieres conocer un poco más sobre como funciona el proceso de autenticación de usuario en Sharepoint Server.

Antes de empezar a ver la propuesta sobre cómo hacerlo veamos algunos conceptos de security en Sharepoint.

En sharepoint cuando hablamos de autentificación no sólo se limita a usuarios, sino que las apps también necesitan autentificarse y por otro lado los servicios que corren en la granja también requieren autentificación a través del ecosistema de Sharepoint. En este post sólo nos centramos en autentificación de usuarios que acceden a un portal Sharepoint.

Cuando creamos una aplicación web desde la administración central podemos escoger entre Windows Claims, Form-Based Claims (FBA) o Trusted identity Provider (SAML trusted identity provider). A priori, la identidad está basada en claims en Sharepoint y para acceder necesitas un token. En esta versión ya no puedes configurar seguridad clásica (sin claims) mediante el site de administración, aunque podrías llegar a configurar mediante powershell seguridad clásica (Windows, Forms sin claims ya no está soportado en esta versión). Si lo hicieses ten en cuenta que hay servicios internos en Sharepoint que sólo soportan ya identidad basada en claims por tanto es posible que no todo funcione como debería si usas un tipo de autenticación clásica en 2013.

Sharepoint se encarga de convertir la identidad a claims una vez te autentificas contra la aplicación web en cuestión. Por ejemplo, si tenemos un site configurado como Windows Claims y marcamos que soporta NTML y Kerberos el usuario que acceda al site mediante un browser introducirá sus credenciales cuando el navegador las solicite, en primera instancia se realiza una autentificación contra el proveedor de identidad que en este caso sería windows (Active Directory, no ADFS!) y en segunda instancia Sharepoint internamente transforma la identidad a windows claims identity...

Si queréis información detallada consultar https://technet.microsoft.com/en-us/library/jj219571.aspx. Aquí podéis ver videos que muestran el proceso de autenticación para windows, fba o trusted idp. Matizar que en la versión Server OnPremise no es necesario configurar el rol ADFS en tu dominio local sino que en Sharepoint hay componentes capacitados para transformar WindowsPrincipal a ClaimsPrincipal y generar el token en cuestión (STS).

Bueno, ya estamos un poco más ubicados. Como has visto si quieres delegar el proveedor de identidad a un servicio externo a Sharepoint puedes hacerlo con los servicios de federación de sharepoint pero necesitarás que el proveedor de identidad soporte SAML y configurarlo para que se "entienda" con Sharepoint. Os paso un articulo donde explican como hacerlo en un Sharepoint 2013 onpremise y ThinkTeckture 2.0. En el escenario donde estoy trabajando se está desarrollando una plataforma de servicios donde hay un proveedor de identidad que no soporta SAML, así que en primera instancia lo que se nos ocurre es ver si es posible configurar un membership personalizado donde tengamos el control... esto nos permite controlar puntos clave como por ejemplo cuando Sharepoint pide validar las credenciales o cuando sharepoint accede al membership para mostrar una lista de usuarios, etc. Si tenemos control de estos puntos nosotros podemos implementar la comunicación contra el idp.

Básicamente lo que has de hacer es crear una aplicación web nueva o extender la que tengas por defecto configurándola para que acepte Forms Based Authentication desde la administración central. (No haría falta windows basic authentication!)


Por otro lado tendrás que crearte un assembly e implementar las clases abstractas MembershipProvider y RoleProvider (en mi caso sólo he implementado MembershipProvider). Si buscas en CodePlex CustomFBA verás ya ejemplos que puedes descargar desarrollados para 2010 pero que funcionan en 2013. Estos ejemplos dan persistencia al membership usando SQLServer que dado el caso podría ser lo que estés buscando...

El siguiente paso es modificar los archivos web.config de los 3 sites que intervienen en este proceso:
  • Configurar Form membership provider + people picker en la web configurada como FBA
  • Configurar Form membership provider + people picker en la web de administración central
  • Configurar Form membership provider en el site que hospeda el servicio STS

Ejemplo web.config (picker):
<PeoplePickerWildcards>
   <clear />
   <add key="AspNetSqlMembershipProvider" value="%" />
   <add key="areaticmembership" value="%" />
</PeoplePickerWildcards>
Ejemplo web.config (membership):
<system.web>   
  <membership defaultProvider="i">
      <providers>
        <add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
        <add name="areaticmembership" type="areaTICCustomFBA.areaTICCustomMembershipProvider, areaTICCustomFBA, Version=1.0.0.0, Culture=neutral, PublicKeyToken=20a4d37db65e35ac" />
      </providers>
    </membership>
    <roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false">
      <providers>
        <add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
      </providers>
    </roleManager>
</system.web>
Ten en cuenta que en el web.config de STS no existe la sección system.web, tendrás que crearla.

Para poder vincular el assembly con tu custom membership tendrás que firmarlo y obtener el código de assembly, si necesitas info sobre como hacerlo te dejo un enlace útil. Falta un paso que es copiar el assembly en los sites... te recomiendo registrarlo en la GAC del servidor/es.

Pues ya lo tienes, si todo ha ido bien al acceder al site te saltará la pantalla de login por defecto. Llegado a este punto te recomiendo configurar Visual Studio para depurar el proceso remoto de Sharepoint, puedes hacerlo instalando las herramientas de depurar en remoto con este enlace https://msdn.microsoft.com/en-us/library/bt727f1t.aspx. Una vez estés depurando el proceso remoto si en el formulario de inicio FBA seleccionas Forms Authentication, introduces unas credenciales y pones un breakpoint en el método ValidateUser podrás seguir el proceso.

Un tema adicional pero interesante es crearte un httpmodule en un assembly, firmarlo como has hecho con este del membership, registrarlo como httpmodule en el site FBA y a STS y entonces puedes poner breakpoints y comprobar el principal del request para ver como va "mutando" automáticamnente de tipo FormsPrincipal a ClaimsPrincipal. No aporta demasiado pero permite comprobar y entender lo que se explica en los videos de technet.

Hasta aquí el post, recuerda que puedes seguir areaTIC a través de las redes sociales y participar en cualquier debate con comentarios. Hasta la próxima!