Tipo de Audencia: Por lo menos el amigo lector haya tenido la experiencia de asignar los permisos predefinidos de SharePoint.
Pareciera que la “herencia” nos hace una mala jugada muchas veces en la Programación Orientada a Objetos según los patrones de diseño, y para la seguridad de SharePoint no es la excepción. Aunque la motivación de SharePoint de heredar los permisos parece buena, no nos permite personalizar los sub-sitios a menos que “rompamos” o “cortemos” la herencia del sitio padre. Supongamos el siguiente caso:
Deseamos crear dentro del portal una sección de Documentación y dentro de ella por Departamento un sub-sitio, pero requerimos que la documentación de cada departamento este visible solamente al grupo de personas que se le indique. En tal caso podemos pensar que no todos tendrán acceso al sitio de documentación de cada departamento.
La estructura de los sitios podría ser como esta:
Por la herencia si tenemos acceso de lectura a la colección de sitos tendremos acceso de lecturas en los demás sub-sitios, y esto no es lo deseable en este caso. Entonces no tenemos otra alternativa que “romper” la herencia de permisos, eliminar los permisos heredados no deseables y posiblemente agregar algunos nuevos.
Imagen de la opción de SharePoint para romper la herencia.
Para el primer nivel o sitio Document Center “romperemos” la herencia de la seguridad y agregaremos nuestros grupos personalizados como lo muestra la imagen de abajo:
Recomendaciones:
Utilice una nomenclatura estándar para el nombramiento de los grupos esto facilitará la búsqueda de los grupos y su asignación. Esta inversión de tiempo luego tendrá sus réditos.
Póngale cuidado a los permisos de cada grupo, como lo muestra la siguiente tabla:
Administradores – Full Control
Colaboradores – Contribute
Lectores y Común - Read
El grupo SP-DOC-Común esta definido para un área común de acceso para los demás sub-sitios.
El grupo SP-DOC-Administradores para los administradores de todos los sub-sitios. No falta alguien que debe de tener acceso a todos de “Full-Control”.
El grupo SP-DOC-Colaboradores para los responsables de subir los documentos en cada sub-sitio.
El grupo SP-DOC-Lectores para aquellas excepciones que si pueden ver todo la información de todos.
Podemos decir entonces que tendremos 6 grupos de seguridad por cada sub-sitio que representa el departamento; Uno para administradores, otro para colaboradores y el último para lectores del departamento y los tres del nivel superior. Como se muestra la imagen de abajo:
Adicionalmente a ello asociaremos a cada grupo de SharePoint un grupo del Directorio Activo de Windows, para que el mantenimiento de los permisos de seguridad sean responsabilidad al área de Infraestructura del departamento de IT, y lo hagan en un ambiente que conocen como lo es el Directorio Activo.
Los nombres de los grupos en el Directorio activo serán:
- DOC-DepartamentoX-Administradores
- DOC-DepartamentoX-Colaboradores
- DOC-DepartamentoX-Lectores.
Imagen de la creación de un grupo dentro de la consola de Grupos y Usuarios del Directorio Activo de Windows 2003.
Tip: Si esta dentro de un Bosque (Forest) defínalo local para que le permita ubicar los usuarios de diferentes dominios.
Finalmente debería obtener una lista como lo muestra la imagen de abajo:
Abajo una imagen de SharePoint asignado a un usuario al grupo de SharePoint, que para este caso el usuario es un grupo del Directorio Activo.
El resultado es el siguiente:
De tal forma que el departamento de IT, no tiene porque ingresar a SharePoint para asignar usuarios, sino desde la consola del controlador de dominio agregar los usuarios a los grupos definidos.
De esta forma podemos decir las siguientes afirmaciones:
- Luego de “romper” la herencia, al definir un grupo nuevo y asignarle permisos dentro del sitio. Allí deberá asignarle los usuarios o grupos del directorio activo. Si este grupo es utilizado en otro sitio no necesitará asignar nuevamente a los usuarios miembros de dicho grupo.
- Ya que se definió un grupo de SharePoint y un grupo del Directorio Activo, esto me permitirá flexibilidad si cambia el directorio activo no afectará los permisos que he definido en SharePoint porque no están tan directamente relacionados. Lo único que tendré que hacer es asignar le grupo nuevo del directorio activo o al usuario directamente al grupo de SharePoint.
- Aunque esta solución no es una de las recomendaciones (“romper la herencia”) de Microsoft. Cuando tenemos este tipo de requerimientos no tenemos otra manera de individualizar los permisos dentro de SharePoint.
Hasta la próxima,
Manolo Herrera
No hay comentarios.:
Publicar un comentario