Vamos hacer un repaso por la autenticación en MOSS13 para poder planificar su alcance, en cada caso.

Introducción

MOSS13 se basa en la creación de Aplicaciones Web. Esto significa un sitio web en el IIS como unidad lógica.

Cómo se ve en el esquema, para crear una Colección de sitios web en MOSS13, necesitamos crear un sitio web en el IIS, enlazarlo a un grupo de Aplicaciones, nuevo y propio, o compartido.

Ese sitio web del IIS tendrá un nombre de dominio único y una base de datos de contenido dedicado.

Tanto al configurar el  IIS como la Base de Datos (SQL Server) tendremos que asociar una cuenta o método de autenticación de MOSS ante el IIS y ante SQL.

Métodos de autenticación

Al crear un sitio web tenemos que contemplar un método de autenticación.

Los métodos de autenticación, lo que hacen, es validar la identidad que nos presenta el usuario. Esa validación se hace ante un proveedor de identidades. Por ejemplo, un AD (Directorio Activo)  o base de datos (SQL).

Esos métodos de autenticación hacer un intercambio de credenciales que afirman una identidad. Nos dice quién es, si es que lo es.

Planificación de la autenticación.

Así que tenemos que establecer los métodos que usaremos para autenticarnos ante una aplicación web de MOSS. La planificación de esa autenticación tiene que pasar por tres elementos:

En primer lugar, el tipo de autenticación, definir que ha de presentar el usuario y que métodos van a transportar hasta el proveedor de identidades, ya sea para una zona o una aplicación web. Para ello, una vez que definimos cada área de seguridad, tenemos que planificar la infraestructura que soportará esa autenticación.

SharePoint 2010

Un caso especial es la planificación es la migración entre MOSS 2010 y 2013. MOSS 2013 tiene, por diseño, el método de notificaciones.

Autenticación: notificaciones

Lo tradicional

Nos movemos en un entorno Windows. Eso significa que estamos en un entorno de AD (Directorio Activo). Presentamos un usuario y password. Dentro de ese entorno, esa seguridad está garantizada. El Directorio Activo decide quién es quién, y qué puede hacer en los activos securizados por el Directorio.

Pero esto no “sale” ente proveedores de identidad de terceros, o en la nube.

Notificaciones

Las notificaciones, un conjunto de notificaciones, es un conjunto de elementos específicos de datos del usuario, los que se decidan. Ese conjunto de notificaciones se unifican en un token que se firma digitalmente. Ese token y esa firma digital lo realiza un proveedor de notificaciones.

Esto se basa, en Microsoft, en WIF, Windows Indentity Foundation, que es un conjunto de clases de .Net Framework. Podemos encontrar la autenticación de usuario, de servidor a servidor o de aplicación.

MOSS13 convierte cualquier método de autenticación en notificaciones. Cuentas de usuario, formularios (SAML) o Windows  en tokens. No se puede pasar al modo clásico, sin notificaciones, si no es por medio de PowerShell.

(Las migraciones de MOSS 2010 conservan el método clásico de autenticación y es recomendable el realizar una migración posterior)

Recorrido de las notificaciones

El comportamiento de MOSS 13 en las notificaciones contra un AD:

Las notificaciones son compatibles con las peticiones de autenticación NTL, Kerberos o básica de Windows, además de los de formularios o SML.

Y eso lo veremos en el siguiente post