Como nos proponemos hablar de aquellos temas sobre los que trabajamos día a día en los CES, este artículo espero que sirva para aclarar los conceptos del modelo de acceso (Autenticación y Autorización) de Microsoft Sharepoint (tanto en Windows SharePoint Services WSS 3.0 como Microsoft Office SharePoint Server 2007).

Hablaremos primero de la organización de los sitios SharePoint, para después describir los métodos Autenticación y Autorización que emplea y finalizar hablando sobre cómo establecer los permisos de acceso adecuadamente.

Sitios SharePoint: Aplicaciones Web y Colecciones de Sitios

SharePoint es una aplicación Web y como tal es Microsoft Internet Information Server (IIS) el encargado de procesar las peticiones de los usuarios inicialmente, que son enviadas como una URL (por ejemplo http://www.cesnavarra.net/cesdigital/Lists/Noticias%20CESDigital/TemaDesarrolloSoft.aspx).

IIS puede soportar múltiples sitios Web, cada uno identificado por su IP, puerto y header o etiqueta de encabezado. La instalación de SharePoint sobre IIS lo que hace es extender un sitio Web de IIS y hacer que sea SharePoint el que se encargue de las peticiones. Esto implica que un mismo IIS puede soportar múltiples aplicaciones Web de SharePoint. El que necesitemos o no diversas aplicaciones Web depende de varios motivos como seguridad o aislamiento de contenidos, etc.

Desde el punto de vista de la seguridad, es cada aplicación Web la que controla el método de autenticación (somos quienes decimos que somos) en cada URL de SharePoint particular, y cada aplicación Web puede usar un método independiente.

En SharePoint 2007 tenemos el concepto de “granjas” que agrupa a un conjunto de servidores Web en los que se ejecuta la misma aplicación Web. Dentro de una granja la definición de cada aplicación Web se distribuye de manera automática (lo que simplifica la tarea de administración) de manera que el mismo método de autenticación se usa de manera consistente, independientemente de qué servidor Web físico usemos.

Cada aplicación Web a su vez acoge una o más colecciones de Sitos, y cada colección a su vez consiste en un sitio raíz y uno o más subsitios.

Todos los sitios en la colección comparten la URL del sitio raíz. Cada sitio a su vez almacena su propio contenido en las listas y librerías de documentos de SharePoint.

Veamos pues los dos pasos que debemos realizar para dar permisos de acceso a nuestros usuarios:

1.   Autenticación: ¿es el usuario quien dice que es?

2.   Autorización: ¿puede el usuario ver lo que quiere ver?

Autenticación

Como hemos comentado, es IIS el que se encarga de autenticar las aplicaciones Web de SharePoint. Para ello, contamos con diversos métodos siendo el más habitual el uso de Active Directory (AD). Sin embargo, dado que soporta cualquier modelo de autenticación de ASP.NET disponemos de mucha más flexibilidad pudiendo por ejemplo emplear los datos de un fichero plano (no muy recomendable, por otra parte…). Para esto se emplea lo que se denomina “membership provider” (MP) que es el responsable de autenticar los usuarios con un método concreto. ASP.NET 2.0 nos proporciona por defecto un MP para SQL, y MOSS añade uno para LDAP.

Cada aplicación Web sólo puede tener un método de autenticación asociado (y por tanto emplea un único MP). Si necesitamos proporcionar acceso al mismo contenido con distintos métodos deberemos extender nuestra aplicación Web a otra zona. Existen cinco zonas disponibles: Default, Internet, Extranet, Intranet y Custom, siendo cada zona básicamente un sitio Web en IIS configurado con un método de autenticación adecuado. La zona “Default” es la empleada por defecto siendo su método de autenticación Windows.

Cuando extendemos una aplicación Web a otra zona le damos una URL concreta para la zona, por lo que podemos usar distintas URL para usar métodos de autenticación distintos para el mismo contenido. En la siguiente imagen vemos esto en acción: en la primera usamos Windows para autenticarnos, en la siguiente Forms.

Podemos definir nuestros MP (que como hemos dicho se emplean al definir el método de autenticación de nuestra aplicación Web) según nuestras necesidades y para esto les daremos un nombre que se nos mostrará cada vez que necesitemos identificar usuarios en SharePoint, para saber a qué usuario nos estamos refiriendo sin dudas.

En el ejemplo siguiente vemos que un usuario nos lo proporciona el propio SharePoint y el otro el S.O. Windows de la máquina sobre la que se ejecuta (WSSV3)

Autorización

Una vez que nuestros usuarios tienen acceso al sistema, debemos conocer a qué contenidos del mismo pueden acceder y qué pueden hacer con ellos, mediante el proceso de autorización.

Para definir la autorización disponemos de 5 componentes:

Permisos individuales

Proporcionan la posibilidad de realizar acciones concretas, como ver los elementos de una Lista (View Items). Estos permisos aplican a nivel de granja web y se pueden controlar por un administrador.

Nivel de permiso

Los niveles de permiso agrupan los permisos individuales para facilitar su gestión. WSS incluye cinco niveles: Acceso Limitado, Lectura, Contribución, Diseño y Control Total. MOSS añade otros como Aprobación y Gestión de Jerarquía. Se pueden añadir niveles de permiso adicionales o modificar los existentes. Su alcance es por cada sitio y pueden heredarse del sitio padre o definirse a nivel de sub-sitio, librería o elemento.

Usuario

Podemos asignar permisos a un usuario particular identificado mediante un método de autenticación, como hemos visto anteriormente.

Grupo

Un grupo es un conjunto de usuarios, que pueden ser bien un grupo de usuarios Windows, un rol proporcionado por un gestor de roles o un grupo de SharePoint, como Propietarios del sitio o Visitantes del sitio. Estos Grupos proporcionan a los administradores de las colecciones de Sitios la flexibilidad para agrupar usuarios sin tener que depender del departamento de Sistemas para que creen grupos de usuarios Windows.

Objeto securizable

Los Grupos anteriores son asignados niveles de permisos sobre objetos securizables concretos: sitios, listas, librerías de documentos, carpetas, documentos o elementos. Por defecto los permisos para listas, librerías, carpetas, documentos y elementos se heredan del padre (sitio, lista o librería en cada caso). Pero aquellas usuarios con Nivel de permiso que incluya la Gestión de Permisos de un objeto securizable particular pueden cambiar los permisos de éste.

SharePoint permite otorgar permisos a nivel de elemento, por lo que para una librería de documentos podríamos conseguir que un usuario tenga acceso a un documento concreto pero no a todos los demás.

Este modelo de permisos también se aplica al interfaz de usuario de SharePoint de manera que podemos lograr que un usuario vea o no partes de nuestra página (Web Parts) sólo si tiene permisos de acceso de lectura adecuados, o que sólo pueda ver aquellas acciones para las que dispone de permisos.

Es recomendable emplear grupos cuando asignemos estos permisos ya que de otra manera nos complicaremos mucho la gestión de permisos en nuestra aplicación. Dar permisos a  un usuario particular es algo que deberíamos emplear sólo de manera excepcional (y eso es válido para cualquier otro sistema).

Almacenamiento de permisos de Usuarios

De acuerdo a lo dicho anteriormente tenemos que los usuarios pueden recibir acceso a los objetos de manera explícita mediante sus cuentas de usuario o implícita por su pertenencia a un grupo de seguridad o rol. El uso de grupos de SharePoint es el método preferido por la facilidad que nos permite.

Cuando un usuario recibe un permiso de acceso a un recurso en una colección de sitios se crea un registro en la tabla UserInfo de la base de datos de contenido asociada a esa colección. Sus detalles se introducen en la lista User Information, y esa información es la que vemos mediante la vista “Todas las personas” (“All People”) de SharePoint. Por tanto, si un usuario tiene diversos accesos a distintas colecciones de sitios existirán un número correspondiente de entradas en la tabla UserInfo de la BBDD de contenido que soporta esas colecciones. Esta tabla contiene un identificador interno propio de SharePoint que sirve como clave en otras tablas, un indicador de si se trata de un grupo de seguridad o un rol y el identificador de seguridad que proporciona el MP empleado en el método de autenticación de la aplicación Web. En el caso básico de emplear autenticación Windows se trata del  Security Identifier (SID) del usuario o grupo. Si concedemos a un usuario acceso implícito a un recurso a través de un grupo de seguridad o rol, la entrada en la tabla UserInfo se crea la primera vez que este usuario accede al recurso.

Existen otras cuatro tablas empleadas para soportar este modelo de autorización: Groups y GroupMembership para grupos y Roles y RoleAssignment para los roles. La tabla Groups contiene la información sobre los grupos (definición, privilegios, etc.) y GroupMembership a su vez enlaza los grupos con los usuarios. Las tablas Roles y RoleAssignment proporcionan los permisos exactos que tiene un usuario o un grupo referidos a su rol concreto en una colección de sitios. Por tanto, para conocer qué permisos tiene una cuenta particular necesitaremos agregar los permisos del grupo de seguridad al que pertenece, los del grupo de SharePoint a que pertenece y los de los roles que le hayan sido asignados. “Sólo” nos falta otro componente: las Web Application Policies, que actúan como un supervisor global a nivel de aplicación Web (es decir, afectan a todas las colecciones de sitios que soportan) y tienen precedencia sobre todo lo demás.

El acceso a los objetos, en definitiva

En SharePoint, cualquier acceso a un recurso consiste en pedir un elemento de un sitio. En la página de inicio pedimos el elemento “default.aspx”, al editar el “EditForm.aspx”, etc. Por tanto, necesitamos seguir un proceso para que el servidor web nos proporcione ese elemento.

Lo primero es autenticarnos con el método de autenticación en un MP. Una vez hecho eso, el MP proporciona un identificador que por simplificar asumiremos que es el SID (es decir, usamos autenticación Windows). Con este SID se obtienen nuestros datos de la tabla UserInfo, en concreto el identificador de SharePoint, con el que obtendrá mediante una combinación de datos del resto de las tablas los permisos de que disponemos y en caso de ser suficientes nos proporcionará el recurso solicitado.

Esto implica que si cambiamos nuestro SID en Windows (por una migración de dominio, habitualmente) tendremos problemas. Para evitarlos, podemos usar la utilidad “stsadm” con el switch “-migrateuser” que reemplazará la cuenta antigua con la nueva. El artículo “Stsadm: Taking control of SharePoint administration” proporciona más información sobre su uso.