Roles de usuario y permisos en Drupal: cómo controlan las universidades quién puede editar qué

Una plataforma web universitaria puede tener varios cientos de editores: administradores de facultad, secretarias de departamento, responsables de comunicación, bibliotecarios y estudiantes en prácticas. Drupal agrupa lo que cada uno de ellos puede hacer en roles y otorga permisos a esos roles en lugar de a las personas individualmente. En este artículo planteamos una estructura de roles que se ajusta a cómo se organiza un campus, cómo dar a cada departamento control editorial sobre sus propias páginas, qué permisos otorgan mucho más de lo que sus nombres sugieren, y cómo retirar el acceso cuando las personas cambian de puesto o se marchan.

La mayoría de las guías sobre este tema explican bien la mecánica y luego se detienen en un ejemplo genérico. Eso deja sin responder la pregunta más difícil: ¿cómo se traduce una organización con facultades, departamentos, centros de investigación y personal estudiantil rotativo en un esquema de permisos que un pequeño equipo central pueda realmente mantener? A continuación desarrollamos esa traducción, nombrando los permisos principales y los módulos contribuidos implicados en cada paso.

Cómo funcionan los roles y permisos en Drupal

Toda acción en un sitio Drupal está regida por un permiso. Cada permiso cubre una acción o un pequeño grupo de acciones, y los permisos los definen los módulos que proporcionan esas acciones. En lugar de otorgar permisos a cuentas individuales, Drupal los agrupa en roles y concede el rol.

Esa distinción importa a escala universitaria. Cuando una secretaria de departamento se marcha, se le retira un rol a una cuenta en lugar de auditar una lista de permisos individuales. Cuando el departamento de comunicación decide que los editores ya no deben poder eliminar páginas, se modifica un solo rol y la decisión se aplica a todos los que lo poseen.

Los tres roles con los que empieza todo sitio

Un sitio Drupal nuevo tiene un rol de usuario anónimo para los visitantes que no han iniciado sesión y un rol de usuario autenticado que recibe automáticamente cualquier cuenta que inicie sesión. Según el perfil de instalación, también puede existir un rol de administrador al que se le asignan todos los permisos del sitio.

De ahí se derivan dos hábitos. Los permisos otorgados al rol de usuario autenticado se aplican a toda cuenta que se cree en el futuro, por lo que ese rol debería mantenerse prácticamente vacío en una plataforma con cientos de editores. Y el rol de administrador debería tratarse como un grupo pequeño e identificado por nombre, no como una comodidad para cualquiera que necesite resolver algo rápidamente.

La cuenta de usuario 1 y por qué nadie debería trabajar con ella

La primera cuenta creada durante la instalación tiene el ID interno 1, y es distinta de todas las demás. Independientemente de los roles que tenga o no tenga, el usuario 1 puede realizar cualquier acción en el sitio: ver y editar todo el contenido, editar cualquier cuenta, cambiar la configuración, instalar y desinstalar módulos, y ejecutar el script de actualización. La propia documentación de Drupal lo compara con la cuenta root de un servidor Linux. Tampoco se puede eliminar desde la interfaz administrativa.

La documentación de Drupal ofrece cuatro razones para crear cuentas administrativas separadas en lugar de compartir esta, y cada una de ellas pesa más en una universidad que en un sitio pequeño.

• Las acciones en el sitio quedan registradas. Si todo el equipo web comparte una sola cuenta, el registro no puede indicar quién modificó la página de inicio.
• El rol de administrador puede configurarse de forma más segura que el usuario 1, de modo que un clic equivocado no pueda desinstalar un módulo.
• Las responsabilidades de las personas cambian. Los roles pueden añadirse y retirarse de una cuenta normal; unas credenciales compartidas no pueden revocarse a una sola persona.
• La autoría del contenido se registra y a menudo se muestra. Las cuentas compartidas hacen imposible saber quién escribió una página.

La regla práctica es guardar las credenciales del usuario 1 en el gestor de contraseñas de la institución, usarlas solo para recuperación y mantenimiento de la plataforma, y dar a cada administrador una cuenta con nombre propio y el rol de administrador.

Los roles se suman, nunca se restan

Un usuario puede tener varios roles a la vez, y los permisos de esos roles se acumulan. No existe ningún mecanismo en el núcleo (core) para que un rol retire un permiso concedido por otro.

Esto sorprende a los equipos con regularidad. Un sitio tiene un rol de editor que puede eliminar contenido, y alguien decide que el personal nuevo no debería poder eliminar nada, así que crea un rol de editor restringido y lo asigna junto al existente. La persona ahora tiene ambos roles, y el permiso de eliminar sigue ahí. La única forma de negar un permiso es construir un rol que nunca lo haya tenido. Cuando un esquema empieza a necesitar una lógica de "resta", esa es la señal de que hay que rediseñar los roles en lugar de añadir otro más.

Un modelo de roles que se ajusta a cómo funciona realmente una universidad

Las estructuras de roles en los campus suelen fallar en una de dos direcciones. O bien hay cuatro roles y cada facultad se queja de que no puede hacer su propio trabajo, o bien hay sesenta roles creados uno a uno según cada solicitud, y nadie recuerda qué otorga la mitad de ellos.

Una estructura que se mantiene sólida con el tiempo suele separar dos preguntas que es fácil confundir. ¿Qué tipo de trabajo hace esta persona, y en qué parte del sitio lo hace? Los roles de Drupal responden bien a la primera pregunta y mal a la segunda, por eso existe más abajo el apartado sobre el territorio editorial.

En cuanto a la primera pregunta, cinco niveles cubren a la mayoría de las instituciones:

• Administrador de la plataforma. Un grupo identificado de dos a cuatro personas en TI central que tienen el rol de administrador y son responsables de la configuración, los módulos y las actualizaciones.
• Editor central. Personal de comunicación y marketing que publica en todo el sitio, incluida la página de inicio y las páginas a nivel institucional.
• Editor de unidad. Personal de facultades y departamentos que crea y publica dentro de su propia área. Es, con diferencia, el grupo más numeroso.
• Colaborador. Académicos, estudiantes en prácticas y colaboradores ocasionales que redactan contenido para que otra persona lo publique.
• Espectador. Cuentas que existen para acceder a páginas restringidas, no para editar, como documentos de política solo para personal.

Merece la pena aplicar dos pruebas antes de añadir un sexto nivel. ¿Se diferenciaría un nuevo rol de uno ya existente en más de dos permisos? ¿Y lo tendrá alguna vez alguien más aparte de quien lo solicita? Un rol creado para una sola persona es, en esencia, una concesión de permisos con pasos adicionales, y seguirá ahí años después de que esa persona se haya marchado.

Dar a los departamentos su propio territorio editorial

Los roles responden a qué puede hacer alguien, pero no a dónde puede hacerlo. Un rol de editor de unidad que otorgue el permiso de editar cualquier página permitirá al departamento de biología editar las páginas de admisiones. Resolver esto requiere una segunda capa, y Drupal ofrece dos enfoques consolidados.

Acceso basado en secciones con Workbench Access

El módulo Workbench Access crea un control de acceso editorial basado en una jerarquía que ya existe, normalmente una taxonomía de facultades y departamentos o la estructura de menús del sitio. El contenido se coloca en una sección editorial al crearse, los usuarios se asignan a secciones por cuenta o por rol, y solo pueden actuar sobre el contenido dentro de sus secciones o las secciones inferiores a ellas. La versión 2.0.5 se publicó en septiembre de 2026 y es compatible con Drupal 9, 10 y 11. Según se informa, lo usan unos ocho mil sitios, y su desarrollo ha sido patrocinado por Palantir.net con el apoyo de Charles Darwin University.

Vale la pena leer con atención dos limitaciones señaladas en su propia documentación antes de construir sobre él. El módulo no concede privilegios editoriales; solo restringe el contenido sobre el que un usuario puede actuar, por lo que los permisos subyacentes de crear y editar siguen teniendo que otorgarse mediante roles. Y controla únicamente el acceso de edición, no quién puede ver el contenido publicado.

Es precisamente la jerarquía lo que hace que este enfoque encaje bien en la educación superior. Un responsable de comunicación de facultad asignado a la sección de la facultad hereda todos los departamentos que están por debajo de ella, mientras que una secretaria de departamento asignada a un solo departamento solo ve ese. Cuando se crea un nuevo centro de investigación, se añade a la jerarquía en lugar de requerir un nuevo rol.

Cuándo Group encaja mejor que las secciones

El módulo Group adopta un enfoque distinto. En lugar de colocar el contenido en una jerarquía, crea colecciones con su propia membresía y sus propios roles internos. Alguien puede ser administrador de un grupo y simple miembro de otro, y los roles de grupo son independientes de los roles a nivel de todo el sitio. Se usa en unos dieciocho mil sitios.

Group se adapta bien a los casos en los que el límite lo marca la pertenencia y no la posición organizativa: un proyecto de investigación con colaboradores nombrados de tres facultades, un comité de conferencia, una comunidad de antiguos alumnos con contenido privado. Donde el límite sigue el organigrama, las secciones son más sencillas de operar.

La elección de versión requiere cuidado a finales de 2026. Las ramas 2.x y 3.x son compatibles con Drupal 10 y 11, la rama 8.x-1.x llegó al final de su ciclo de vida junto con Drupal 10 a mediados de 2026, y una rama 4.x para Drupal 11.4 y superior está en fase alpha. Una plataforma que se ponga en marcha ahora no debería empezar por la rama más antigua.

Roles en una plataforma multisitio

En una plataforma donde cada facultad gestiona su propio sitio a partir de una única base de código, los roles y los usuarios no se comparten entre esos sitios por defecto. Cada sitio tiene sus propias cuentas y su propia configuración de roles, lo cual es una ventaja para la autonomía y una carga para la coherencia: una definición de rol mejorada en un sitio no mejora en ningún otro. Exportar la configuración de roles y desplegarla en todos los sitios mantiene las definiciones idénticas aunque las cuentas sigan siendo independientes. Tratamos las compensaciones más amplias de esa arquitectura en gestión de sitios web universitarios con Drupal multisitio.

Este es también el punto en el que se hace visible la elección entre multisitio y secciones. Si los departamentos necesitan sitios independientes, los roles viven por sitio. Si necesitan un territorio separado dentro de un mismo sitio, las secciones hacen el trabajo.

Permisos que silenciosamente lo conceden todo

Algunos permisos se leen como comodidades administrativas menores, pero en la práctica equivalen a entregar el sitio por completo. El propio Drupal señala los más peligrosos: un permiso puede declararse con una marca de acceso restringido en la definición de su módulo, lo que hace que la página de permisos muestre junto a él una advertencia de seguridad estándar. El core lo usa, por ejemplo, para permisos como administrar formatos de texto y filtros.

En una página con varios cientos de casillas de verificación, es fácil pasar por alto la advertencia, así que estos merecen nombrarse.

• Administrar permisos. Cualquiera que lo tenga puede concederse a sí mismo o a cualquier otra persona cualquier permiso del sitio, incluido este mismo.
• Administrar usuarios. Permite editar cualquier cuenta. Combinado con el permiso anterior, o en un sitio donde se puede editar una cuenta de administrador, es una vía hacia el control total.
• Administrar formatos de texto y filtros. Controla qué HTML está permitido y qué roles pueden usar qué formato. Relajar un formato es la forma en que la inyección de scripts entra en un sitio a través del editor.
• Omitir el control de acceso al contenido. Anula cualquier otro permiso de contenido, incluido todo lo que apliquen Workbench Access o Group.
• Administrar la configuración del sitio. Alcanza ajustes que afectan a toda la plataforma, no a una sola sección del sitio.
• Administrar módulos. Instalar código es el camino más directo para ejecutar código arbitrario en el servidor.

La regla que se deriva de esto es breve. Estos permisos pertenecen al rol de administrador de la plataforma y a ningún otro. Cuando llega una solicitud de alguno de ellos, la respuesta útil es preguntar qué intenta hacer realmente la persona, porque la respuesta casi siempre es un permiso más limitado o una asignación de sección.

Vale la pena corregir una afirmación que circula en escritos más antiguos sobre este tema: que los módulos contribuidos son inherentemente menos seguros que el core. Los módulos contribuidos con versiones estables están cubiertos por la política de avisos de seguridad de Drupal, y todos los módulos mencionados en este artículo cuentan con esa cobertura. Lo que sí varía es el estado de mantenimiento, que se indica en la página de cada proyecto y es lo que hay que comprobar.

Dejar que los departamentos gestionen a su propio personal

Con unos cientos de editores, cada cambio de cuenta que pasa por TI central se convierte en una cola de espera. Un departamento contrata a una administradora en septiembre y espera una semana para obtener acceso de edición. La solución instintiva es dar al jefe de departamento la capacidad de gestionar usuarios, lo que significa otorgar los permisos de administrar usuarios y administrar permisos, lo que a su vez significa que el jefe de departamento ahora puede concederse a sí mismo cualquier cosa.

Para esto existe el módulo Role Delegation. Crea un permiso de asignación independiente para cada rol del sitio, de modo que a un administrador de facultad se le puede dar la capacidad de asignar el rol de colaborador y nada más. Ven un widget de asignación de roles en los formularios de cuenta y en las operaciones masivas de la lista de usuarios, sin tener en ningún momento el permiso de administrar permisos. Se reporta su uso en más de cincuenta mil sitios, y su versión actual es compatible con Drupal 10.3 y 11.

La delegación funciona mejor con una regla clara sobre qué roles pueden delegarse: editor de unidad y colaborador, sí; editor central y administrador de la plataforma, no. Eso mantiene la incorporación diaria de personal a nivel local, mientras que los roles con poder real permanecen en el equipo central.

Asignar roles desde el sistema de identidad del campus

La asignación manual no escala en un campus, y tampoco es necesario que lo haga. Cuando el personal inicia sesión a través del proveedor de identidad de la institución, los atributos liberados en ese inicio de sesión pueden determinar directamente la asignación de roles, de modo que la pertenencia a un grupo de directorio se convierte en un rol de Drupal sin que nadie toque la cuenta. Tratamos el aspecto de la autenticación en integración de SSO con SAML, Shibboleth, LDAP y CAS; lo que sigue es lo que ocurre después de que llega la identidad.

Dos familias de módulos lo hacen posible. El módulo simpleSAMLphp Authentication ofrece la creación de cuentas justo a tiempo (just-in-time) y la asignación automática de roles a partir de atributos SAML, y sigue estando ampliamente desplegado. Su página de proyecto tiene ahora el estado de "mantenimiento mínimo", y su propio mantenedor recomienda evaluar en su lugar el módulo SAML Authentication, que tiene una cadena de dependencias mucho más reducida. Ese segundo módulo gestiona la asignación de roles a través de su submódulo de roles de usuario, y un módulo complementario asigna los atributos SAML a la pertenencia a Group para las instituciones que usan grupos en lugar de secciones.

Sea cual sea la vía elegida, tres decisiones de diseño importan más que la elección del módulo. Decidir qué atributo es el de referencia, normalmente un grupo de directorio en lugar de un campo de puesto de trabajo. Decidir qué ocurre en cada inicio de sesión: si los roles se recalculan cada vez, lo que hace que la retirada sea automática, o si se asignan una sola vez al crear la cuenta, lo cual no lo consigue. Y mantener un pequeño conjunto de roles fuera del mapeo automatizado, porque el rol de administrador de la plataforma debería ser un acto deliberado y no la consecuencia de un cambio en el directorio.

La parte que la mayoría de las instituciones se saltan: retirar el acceso

Los esquemas de permisos se diseñan en el lanzamiento y, a partir de ahí, solo se les van añadiendo cosas. El acceso se acumula: el estudiante en prácticas que se graduó, el responsable que se trasladó a otra facultad, la agencia que construyó el sitio hace tres años. Cada una de esas cuentas sigue siendo una vía de entrada.

Una universidad tiene una versión particular de este problema porque la rotación es estacional y predecible. El personal estudiantil cambia cada trimestre o semestre. Las funciones administrativas académicas rotan anualmente. Los departamentos se fusionan. Nada de esto genera una notificación al equipo web.

Tres hábitos cubren la mayor parte del riesgo.

• Vincular la desactivación al sistema de identidad. Si las cuentas se aprovisionan desde el directorio y los roles se recalculan en cada inicio de sesión, una persona que pierde su grupo de directorio pierde sus derechos de edición sin que nadie tenga que presentar una solicitud.
• Revisar los roles según el calendario académico en lugar de una fecha arbitraria. Una comprobación al inicio de cada trimestre o semestre detecta la rotación de estudiantes mientras el cambio aún es reciente.
• Bloquear las cuentas en lugar de eliminarlas. El bloqueo retira el acceso a la vez que mantiene intacta la autoría, de modo que sobrevive el historial de quién escribió qué.

Una lista breve de quién tiene los roles de administrador de la plataforma y editor central, revisada una vez por trimestre o semestre por una persona designada, vale más que cualquier cantidad de documentación de políticas.

Los datos personales y la capa de permisos

En cuanto un sitio incluye formularios de solicitud, inscripciones a eventos o registros de estudiantes extraídos de otro sistema, el esquema de permisos deja de ser una comodidad editorial y pasa a ser un control de protección de datos.

En Estados Unidos, la FERPA distingue entre los registros educativos y la información de directorio, y qué campos caen en cada categoría es una decisión que corresponde a la secretaría académica (registrar), no al equipo web. En la Unión Europea y el Reino Unido, el principio de minimización de datos del RGPD apunta en la misma dirección: las personas deberían llegar solo a los datos que su trabajo requiere, y no más.

De ahí se derivan tres puntos prácticos. El control de permisos a nivel de campo permite que un formulario recoja un dato que la mayoría de los editores no podrán volver a leer, la forma correcta de tratar los datos de contacto en un formulario de consulta. El acceso a los datos enviados debería ser un rol independiente de la capacidad de editar la página que contiene el formulario, porque la persona que mantiene la página de un programa rara vez necesita ver las solicitudes recibidas. Y el permiso para ver contenido no publicado es más amplio de lo que parece, ya que los borradores suelen contener precisamente el material que todavía no se ha autorizado para su publicación.

Revisar y probar un esquema de permisos

Un esquema de permisos es configuración, lo que significa que puede exportarse, revisarse del mismo modo que el código y desplegarse, en lugar de irse ajustando a golpe de clic directamente en el sitio en producción. Las instituciones que lo tratan así pueden responder, incluso meses después, a la pregunta de qué cambió y cuándo.

Las pruebas son el paso que se suele saltar. La única comprobación fiable es mantener una cuenta de prueba para cada rol, iniciar sesión con ella e intentar hacer las cosas que ese rol no debería poder hacer. Leer la página de permisos indica lo que se ha configurado; usar la cuenta indica lo que realmente se ha construido. Vale la pena mantener en la plataforma una cuenta de prueba inactiva por rol exactamente para este propósito.

Vale la pena señalar con claridad un límite, porque genera confusión. Los permisos determinan qué se le permite hacer a una persona. El flujo de trabajo editorial determina en qué estado se encuentra un contenido y quién lo hace avanzar al siguiente. Que un colaborador pueda crear una página pero no publicarla es una decisión de permisos; que una página permanezca en revisión hasta que un editor la apruebe es una decisión de flujo de trabajo. Ambos funcionan juntos, y el segundo lo tratamos en flujos de aprobación de contenido para universidades.

Planificar la estructura de roles

El trabajo que determina si un esquema de permisos perdura no es la configuración. Es decidir qué unidades son propietarias de qué partes del sitio, quién puede publicar sin revisión, qué roles puede asignarse una facultad por sí misma y qué ocurre cuando alguien se marcha. Esas respuestas vienen de la institución, y Drupal las aplica después.

Una secuencia razonable consiste en mapear primero la propiedad existente del contenido, definir el conjunto más pequeño de roles que cubra el trabajo, añadir una jerarquía de secciones para que esos roles se apliquen solo dentro de una unidad, delegar los dos roles inferiores a las facultades, conectar la asignación al sistema de identidad, y fijar una fecha de revisión en el calendario académico antes de que la plataforma salga en producción, no después.

Las plataformas Drupal que el equipo de Drupal4edu en Drupart ha construido para instituciones como la Universidad Sabancı, la METU y la Universidad Técnica de Yıldız están diseñadas exactamente en torno a esta capa, donde un pequeño equipo central mantiene la coherencia de la plataforma mientras cada facultad edita sus propias páginas. Puede leer más sobre nuestro enfoque en la página Drupal para educación.

Preguntas frecuentes sobre roles y permisos en Drupal

Última actualización: 18.09.2026 16:06