SharePoint 2013: ¿Cuando tengo que desarrollar Aplicaciones y cuando Soluciones?

Como sabéis, SharePoint 2013 (al igual que las versiones previas) es una plataforma completamente extensible mediante desarrollo y a través de un espectro de posibilidades de desarrollo. Además, en la nueva versión del producto se incorpora un nuevo modelo de desarrollo: el modelo de creación de aplicaciones. En este posts repasaremos las opciones de despliegue que tenemos en SharePoint 2013, las posibilidades de desarrollo que tenemos y por último cuando utilizar cada modelo de desarrollo.

Opciones de despliegue

Las posibilidades son:

  • On-Premise, es decir, disponemos de SharePoint instalado en un entorno corporativo lo que proporciona un nivel máximo de flexibilidad en cuanto a posibilidades de desarrollo y herramientas.
  • SharePoint Online, lo que implica que no podemos crear y desplegar soluciones de tipo granja ya que Microsoft no lo permite.
  • Instalación “hospedada”, lo que implica que un tercero ha instalado SharePoint 2013 y ofrece su uso en modo hosting. Esta opción es muy similar al desarrollo para SharePoint Online en cuanto a qué las posibilidades de desarrollo pueden ser similares.

Opciones de desarrollo

Como opciones de desarrollo tenemos las siguientes posibilidades:

  • Soluciones de tipo granja, opción que apareció con SharePoint 2007 y qué solo está permitida para escenarios On-Premise.
  • Soluciones de tipo sandbox, opción que apareció con SharePoint 2010 y qué está permitida para los tres tipos de opciones de despliegue comentados.
  • Aplicaciones hospedadas en SharePoint, opción que aparece con SharePoint 2013 y que está disponible para todos los tipos de despliegue. Implica que las aplicaciones se desplieguen en una colección de sitios aislada (que actúa como hoster) y toda su lógica se ejecuta en cliente (en el navegador). Una aplicación de este tipo no puede interactuar con otras aplicaciones.
  • Aplicaciones hospedadas por un proveedor (un tercero), opción que también aparece con SharePoint 2013 y que también está disponible para todos los tipos de de despliegue. Las aplicaciones se despliegan en sitios de SharePoint y su lógica se ejecuta normalmente en código de servidor externo a SharePoint como puede ser en otro servidor o en la nube. Este tipo de aplicaciones tampoco puede interactuar con otras aplicaciones.
  • Aplicaciones hospedadas en Azure, opción que también aparece con SharePoint 2013 y qué solo está disponible para SharePoint Online en Office 365. Este tipo de aplicaciones es similar al anterior en cuanto a qué están formadas por componentes externos. Estos componentes se restringen a sitios web y opcionalmente a BDs SQL Azure que se incluyan. En este caso, cuando la aplicación se instala SharePoint automáticamente provisiona y despliega estos componentes a Windows Azure. De nuevo, una aplicación de este tipo no puede interactuar con otras.

Herramientas de desarrollo

Se disponen de diferentes herramientas de desarrollo que pueden ser utilizadas para cada una de las opciones de desarrollo comentadas:

  • El navegador web, y en concreto para SharePoint Online tenemos la herramienta NAPA que permite crear aplicaciones a desarrolladores que no disponen de Visual Studio.
  • SharePoint Designer para creación rápida de soluciones y elementos como flujos de trabajo o tipos de contenido externo. Está disponible para los tres tipos de despliegue.
  • Visual Studio, nos permite crear todos los tipos de aplicaciones comentados.
  • Otros como Eclipse, LAMP ya que SharePoint 2013 habilita el uso de aplicaciones que residen fuera de SharePoint por lo que cualquier tecnología, lenguaje de programación y plataforma es posible. Esta opción sólo es posible para Aplicaciones de tipo “Developer-Hosted”.

Vale, y ahora la pregunta del millón: ¿Qué tipo de aplicación debería crear? La recomendación de Microsoft es crear aplicaciones de acuerdo al nuevo modelo de aplicaciones que aporta ventajas como:

  • Mayor flexibilidad en cuanto a la elección de tecnologías de desarrollo, capacidades e infraestructura.
  • El aislamiento a nivel de proceso, datos y usuario es mayor.

Si pensamos en soluciones de tipo granja, las usaremos en situaciones en las que se necesite un alto grado de personalización como:

  • Provisionar páginas maestras, diseños de página, elementos de biseño.
  • Desplegar elementos de administración avanzados como pueden ser páginas de administración, Timer Jobs, etc.

Entonces, a la hora de escoger entre Aplicaciones y Soluciones (Granja o Sandbox) podemos hacernos preguntas como:

  • ¿Se necesita código personalizado que utilice el modelo de objetos en servidor de SharePoint? Entonces, tendremos que recurrir a soluciones de tipo granja o Sandbox teniendo en cuenta que en estas últimas no se puede utilizar el modelo de objetos completo.
  • ¿Tiene la extensión qué desplegar componentes con un ámbito más amplio que sitio (SPWeb) o tiene que acceso a componentes de SharePoint fuera del sitio dónde se ha desplegado? Una aplicación de SharePoint puede acceder y otras fuentes que no están hospedadas en SharePoint, pero si se trata de aplicaciones de tipo “SharePoint hosted”, sólo pueden acceder a componentes dentro del sitio dónde se han instalado. Sin embargo, una aplicación externa a SharePoint si puede acceder a ese contenido externo siempre y cuando se garanticen los correspondientes servicios cuando se instala.
  • ¿Se necesitan desplegar componentes que no pueden ser incluidos en Soluciones de tipo Sandbox (páginas de aplicación, definiciones de sitio)? Entonces, iremos de nuevo por soluciones de tipo granja ya que en las Aplicaciones tampoco es posible desplegar este tipo de componentes.
  • ¿Quién es el usuario objetivo? Tendremos que distinguir entre usuarios administradores de la granja, usuarios administradores de colecciones de sitios y usuarios administradores de sitios para determinar si necesitan funcionalidad desplegada en la forma de soluciones o aplicaciones.
  • ¿Existe algún tipo de acoplamiento con otras extensiones de SharePoint existentes? Hay que tener en cuenta que esto no es posible en Aplicaciones de SharePoint ya que un requerimiento de las mismas es que se tienen que instalar y desinstalar de forma limpia sin dejar ningún tipo de rastro en el sistema.
  • ¿Cómo de grande es la extensión? Las aplicaciones de SharePoint no debería ser en ningún caso una aplicación completa, como Word, Excel, Access o Visio.

SharePoint 2013: Como configurar la autenticación basada en formularios (I)!

Como en versiones anteriores, podemos configurar SharePoint 2013 para que usuarios de distintos tipos (Directorio Activo, Base de Datos, directorio LDAP, etc) puedan autenticarse en sitios de SharePoint usando las credenciales que tengan definidas. En este primer post vamos a ver como configurar la autenticación basada en formularios para usuarios de base de datos. Empecemos (Nota: Es recomendable hacer una copia de seguridad de todo archivo web.config que se modifique).

Creación de la aplicación web con soporte para FBA

Lo primero que tenemos que hacer es crear una aplicación web de SharePoint 2013 con soporte para FBA. Os recuerdo, que por defecto SharePoint 2013 utiliza autenticación basada en claims por lo que ya no podremos elegir entre autenticación clásica y claims al crear la aplicación:

  • Por un lado, configuraremos la aplicación web para que use autenticación Windows integrada (NTLM).
  • Por otro lado, habilitaremos la autenticación por formularios y especificaremos los nombres del proveedor de suscripciones y del proveedor de administración. Estos nombres los necesitaremos posteriormente cuando modifiquemos los correspondientes archivos web.config.
image image

 

Creación de la base de datos de roles y usuarios

Una vez que hemos creado la aplicación web, pasaremos a crear la BD de roles y usuarios utilizando para ello la clásica utilidad aspnet_regsql.exe:

  • Abrimos la interfaz de línea de comandos y buscamos esta utilidad en la ruta c:\Windows\Microsoft.NET\Framework\v2.0.50727.
  • Ejecutamos la utilidad de forma que vía asistente y de forma guiada se cree la BD de roles y usuarios comentada. Una vez qué el proceso de creación concluye, comprobamos que la BD se ha creado de forma correcta.
  • Lo siguiente que haremos es agregar usuarios en dicha BD. Para ello, creamos un proyecto de ASP.NET vacío en Visual Studio 2012 y usamos la opción “Configuración de ASP.NET” disponible en el menú “SITO WEB”.
image image image

Modificación de los archivos web.config

Realizados los pasos anteriores, para habilitar y utilizar la autenticación basada en formularios tenemos que proceder a modificar los archivos web.config siguientes: el de la aplicación web creada, el de la Administración Central de SharePoint 2013 y el del STS. Antes de modificar cualquier archivo web.config, os recomiendo hacer una copia de seguridad del mismo para evitar problemas y modificaciones incorrectas.

Archivo “web.config” de la Aplicación Web

  • Añadimos la cadena de conexión después de la etiqueta </SharePoint> y antes de <system.web>:
  <connectionStrings>
    <add connectionString="Server=c4431163311;Database=aspnetdb;Integrated Security=true" name="AspNetSqlProvider" />
  </connectionStrings>

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

  • Añadimos el membership Provider y Role Manager (reemplazar el otro RoleManager y Membership existente en el web.config):

    • Localizamos la sección <roleManaer defaultProvider=“c”…> y la configuramos de la siguiente forma:

    <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" />
        <add connectionStringName="AspNetSqlProvider" applicationName="/" description="Stores and retrieves roles from SQL Server" name="SQL-RoleManager" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
      </providers>
    </roleManager> 

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

    • A continuación localizamos la sección <membership defaultProvider="i"> y la configuramos de la siguiente forma:

    <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 connectionStringName="AspNetSqlProvider" passwordAttemptWindow="5" enablePasswordRetrieval="false" enablePasswordReset="false" requiresQuestionAndAnswer="true" applicationName="/" requiresUniqueEmail="true" passwordFormat="Hashed" description="Stores and Retrieves membership data from SQL Server" name="SQL-MembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
      </providers>
    </membership>

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Archivo “web.config” de la Administración Central

En el archivo “web.config” de la Administración Central de SharePoint 2013 realizamos las siguientes modificaciones:

  • Añadimos la cadena de conexión (después de la etiqueta </SharePoint> y antes de <system.web>:
  <connectionStrings>
    <add connectionString="Server=c4431163311;Database=aspnetdb;Integrated Security=true" name="AspNetSqlProvider" />
  </connectionStrings>

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

  • Localizamos la sección <roleManager> dentro de <System.web> y la reemplazamos por el siguiente contenido:

    <roleManager defaultProvider="AspNetWindowsTokenRoleProvider" enabled="true" cacheRolesInCookie="false">
      <providers>
        <add connectionStringName="AspNetSqlProvider" applicationName="/" description="Stores and retrieves roles from SQL Server" name="SQL-RoleManager" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
      </providers>
    </roleManager>
  • A continuación localizamos la sección <mebership> y la configuramos de la siguiente forma:
    <membership defaultProvider="SQL-MembershipProvider">
      <providers>
        <add connectionStringName="AspNetSqlProvider" passwordAttemptWindow="5" enablePasswordRetrieval="false" enablePasswordReset="false" requiresQuestionAndAnswer="true" applicationName="/" requiresUniqueEmail="true" passwordFormat="Hashed" description="Stores and Retrieves membership data from SQL Server" name="SQL-MembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
      </providers>
    </membership>

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Archivo “web.config” del STS

Una vez que hemos modificado el web.config tanto del sito como de la Administración Central, tenemos que modificar también el archivo web.config del STS qué se encuentra en la ruta C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\WebServices\SecurityToken:

  • Añadimos antes de la etiqueta de cierre </configuration> el string de conexión a la BD De aspnetdb.
  <connectionStrings>
    <add connectionString="Server=c4431163311;Database=aspnetdb;Integrated Security=true" name="AspNetSqlProvider" />
  </connectionStrings>

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

  • Añadimos una nueva entrada <system.web> dentro de la sección <Configuration> con el siguiente contenido:
  <system.web>
    <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" />
        <add connectionStringName="AspNetSqlProvider" applicationName="/" description="Stores and retrieves roles from SQL Server" name="SQL-RoleManager" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
      </providers>
    </roleManager>
    <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 connectionStringName="AspNetSqlProvider" passwordAttemptWindow="5" enablePasswordRetrieval="false" enablePasswordReset="false" requiresQuestionAndAnswer="true" applicationName="/" requiresUniqueEmail="true" passwordFormat="Hashed" description="Stores and Retrieves membership data from SQL Server" name="SQL-MembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
      </providers>
    </membership>
  </system.web>

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Probando la autenticación por FBA

Guardamos los cambios realizados en todos los archivos web.config y procedemos a comprobar el funcionamiento de la autenticación basada en formularios:

  • Revisamos que tanto la Administración Central de SharePoint como el sitio siguen estando operativos y no hay ningún problema debido a las modificaciones realizadas en el archivo web.config.
  • En el sitio de trabajo, elegimos como opción de autenticación “Autenticación de formularios”.
  • En la nueva página que se abre, especificamos el login y contraseña del usuario que creamos con anterioridad.
  • Accedemos de nuevo al sitio para autenticarnos por FBA y comprobamos que el usuario ya puede acceder sin problemas.
image image image

Referencias