Arquitectura, buenas prácticas y desarrollo sobre la nueva herramienta de Microsoft SharePoint 2016

Sobre usuarios, grupos SharePoint y Active Directory

Una buena práctica entorno al uso de usuarios/grupos de SharePoint es crear un grupo de SharePoint, que a su vez esté formado por un grupo de Active Directory.

Las ventajas de esta práctica son:

  • Facilita la gestión de los permisos al departamento de Sistemas
  • Simplifica la Gobernabilidad de nuestra granja SharePoint

¿Qué problemas nos encontramos?

  • La organización del departamento de IT

Tienen una distribución/dependencia que hace que los responsables de la granja de SharePoint no quieran que el correcto funcionamiento de sus sitios dependa de otros departamento. Por lo que (generalmente), en estos casos el resultado es que hay dos departamentos que se encargan de gestionar permisos, con lo que se duplican esfuerzos y se duplica la posibilidad de fallo e inconsistencia.

  • El desarrollo

En muchos post hemos comentado que el desarrollo sobre SharePoint depende mucho del conocimiento sobre la plataforma. Para obtener un mismo resultado tenemos múltiples posibilidades, pero no todas las opciones son las adecuadas. Con el tema de los grupos/usuarios NO iba a ser una excepción. Recientemente ya hablé sobre la legibilidad de la propia API de SharePoint. En este caso, la problemática radica sobre los grupos a los que pertenece un usuario para realizar una acción u otra.

Caso de Uso

Tenemos una lista de noticias de nuestra organización que debemos de mostrar en la Home de la Intranet dependiendo del grupo a la que pertenezca un usuario. De tal forma que cuando el publicador añade una nueva noticia, indica al departamento/s a los que le interesa. En la Intranet disponemos de un grupo de SharePoint por cada Departamento de nuestra organización. A su vez, dentro de cada grupo de SP, hay un grupo de AD con los integrantes de dicho departamento.

Primera Opción

Dentro del Contexto de SharePoint, disponemos un objeto que nos indica el Usuario que está autenticado contra SharePoint y con este objeto podemos obtener los grupos  a los que pertenece dicho usuario. Con un código similar al siguiente:

   SPUser currentUser = SPContext.Current.Web.CurrentUser;
   SPGroupCollection grpColl = currentUser.Groups;

¿Este código funciona?

Como podréis deducir este código no funciona o por lo menos no nos devuelve los grupos a los que pertenece este usuario. Si vamos a nuestro desarrollo, no visualizamos ninguna noticia. Si agregamos de forma individual a un usuario a un grupo con este mismo código, nuestro desarrollo ahora mismo funciona.

Los primeros pensamientos son como SharePoint se comporta Out of the Box con los grupos de AD y funciona tal y como esperamos. Es decir, si asignamos un permiso a un Grupo de AD, todos los usuarios que pertenecen a ese grupo tienen dicho permiso.
Ahora bien, ¿hay otra posibilidad para saber si un usuario pertenece a un determinado grupo?

La respuesta rotundamente es SÍ. Un ejemplo sería este código:

  private IList<SPGroup> GetGroupsUser(SPWeb web)
        {
            IList<SPGroup> groupCollection = new List<SPGroup>();

            foreach(SPGroup group in web.SiteGroups)
            {
                if (group.ContainsCurrentUser)
                {
                    groupCollection.Add(group);
                }
            }
            return groupCollection;
        }

Ahora bien, ¿qué está ocurriendo?

Pues seguramente algo que nos ha pasado en algunas ocasiones y es que hay varios grupos de desarrollo que no se hablan entre sí e implementan funcionalidad similar de forma distinta. Esto ocasiona no sólo que el código sea difícil de mantener, sino que funcionalidad igual de un resultado diferente. A la hora de desarrollar, siempre es un bueno seguir unas buenas prácticas y una buena comunicación en el equipo, para evitar fallos que son subsanables con hablar.

¿Es un Bug de la API de SharePoint?

En la versión 2013 por lo menos si que lo es, ya que el funcionamiento de la API va en contra del funcionamiento por la propia interfaz. Con el cambio a la versión 2013, la forma de autenticación de cambio a claims posiblemente afectará a este método. Dado que ahora mismo no he tenido un entorno de 2010 para poder verificar este funcionamiento en otras versiones. Mi compañero Alberto Díaz dice que tenemos que tener en cuenta que SharePoint es un monstruo que ha ido evolucionando con multitud opciones desde su versión de 2003, pero también tenemos que ser conscientes de estos fallos para mejorar el producto y corregirlo 🙂

mm

Sobre Adrián Díaz

Adrián Díaz es Ingeniero Informático por la Universidad Politécnica de Valencia. Es MVP de Microsoft en la categoría Office Development desde 2014, MCPD de SharePoint 2010, Microsoft Active Profesional y Microsoft Comunity Contribuitor 2012. Cofundador del grupo de usuarios de SharePoint de Levante LevaPoint. Lleva desarrollando con tecnologías Microsoft más de 10 años y desde hace 3 años está centrado en el desarrollo sobre SharePoint. Actualmente es Software & Cloud Architect Lead en ENCAMINA.
Esta entrada ha sido publicada en buenas practicas, desarrollo. Enlace permanente.
Suscríbete a Desarrollando sobre SharePoint

Suscríbete a Desarrollando sobre SharePoint

Recibe todas las actualizaciones semanalmente de nuestro blog

You have Successfully Subscribed!

ENCAMINA, piensa en colores