Diferencia entre revisiones de «Roles»

Revisión actual del 10:33 27 abr 2009

¿Qué es un rol?

Un rol es un recurso de ODL cuyo objetivo es limitar el acceso a los usuarios que van a interactuar con los diferentes elementos que intervienen en un sistema de información.

Un rol por sí solo no permite ni restringe ningún acceso, sino que en él se incluyen permisos que se encargarán de especificar el nivel de acceso que va a tener un usuario a elementos concretos del sistema de información.

¿Y qué clase de permisos podemos asignar a un rol?

Definición, sintaxis y herencia

La definición de un rol sólo se permite realizar como definición de tipo, es decir, con la palabra reservada tipo. No se permiten las definiciones de rol ([Nombre] <code>es rol</code>). Estas definiciones de tipo, se podrán declarar como abstractas, de manera que dicho rol no podrá ser asignado a ningún usuario.

Al igual que cualquier definición en ODL, la definición de roles también permite la herencia. Esto permite heredar permisos entre un rol derivado y un rol padre, además de poder redefinir permisos heredados.

La sintaxis de la definición de un rol debe ser la siguiente:

tipo [Nombre] es rol
    ...
    ...
    Asignación de permisos
    ...
    ...
fin

Tipos de permisos

Ya sabemos que los permisos habilitan a un usuario para que acceda a los elementos del sistema. Pero, ¿a qué elementos podemos acceder?

Permisos sobre contenedores

Para acceder a cualquier objeto, ya sea de sistema o no, será necesario incluir un permiso asociado a la definición de contenedor a la que pertenezca el objeto. Para esto, tendremos tres tipos de permisos dependiendo del nivel de acceso que queramos adquiera el usuario:

• abrir: sólo puede abrir los objetos de ese tipo, pero no modificarlo ni crear nuevos. Tampoco puede eliminar.
• modificar: puede abrir los objetos existentes y modificarlos, pero no crear nuevos. Tampoco puede eliminar.
• crear: tiene todos los permisos sobre los objetos de ese tipo. Puede crear, modificar, abrir y eliminar (no válido para objetos de sistema).
• Sin_Acceso: impide el acceso a los objetos del tipo indicado.

La sintaxis para definir un permiso a un objeto es la siguiente:

accede [Definición de contenedor]: permiso;

Permisos sobre habitaciones

Otro recurso de ODL a los que puede acceder un usuario son las habitaciones. Éstas se utilizan para representar las oficinas de una organización. Por ello, el único permiso que se puede dar a un usuario es el de acceso a dicha oficina:

• entrar: permite al usuario acceder a una habitación (oficina) concreta.
• Sin_Acceso: impide el acceso a la habitación indicada.

Su sintaxis sería la siguiente:

accede [Definición de habitación]: entrar;

Permisos sobre tareas

Las tareas son también recursos de ODL a los que hay que limitar su acceso. En nuestro centro, cada tipo de usuario tendrá designado ciertas tareas, de modo que en la definición de rol correspondiente habrá que especificar de qué tareas se tratan.

Para las tareas no existen niveles de acceso como para los objetos. Simplemente se realizan o no se realizan. De manera que su sintaxis sería la siguiente:

realiza [Definición de tarea]

NOTA: Un usuario que tenga asignado la realización de una tarea, automáticamente tendrá asignados todos los niveles de acceso que afecten a los objetos que se puedan abrir, modificar o crear durante la realización de la tarea. Por tanto, no será necesario incluir estos permisos explícitamente en la definición del rol.

Permisos sobre firmas

Por último, existe otro tipo de acción a realizar por los usuarios de un centro que es el firmado de documentos. En una organización, institución o empresa se generan documentos que han de ser firmados por las personas indicadas para este fin. Por tanto, habrá que definir un rol específico para este tipo de usuarios donde se incluirán los permisos para la realización de las firmas. La sintaxis para firmar un documento (campo firma) es la siguiente:

firma [Definición de contenedor]:[Formulario].[Sección/es(si las hubiere)].[Campo firma];

Recursos públicos y privados

A la hora de definir un rol, hay un aspecto importante a tener en cuenta. Las definiciones de contenedores en ODL están definidas por defecto como "públicas". Esto quiere decir que cualquier objeto del sistema es accesible por cualquier usuario del centro, tenga o no permisos de acceso en su rol a las definiciones del contenedor. El atributo publico es el encargado de determinar este comportamiento, cuyo valor por defecto es verdadero. Por tanto, habrá que darle valor falso en cada definición de contenedor del centro que queramos que no sea accesible. Una vez los contenedores no sean públicos, entonces incluímos los permisos que posibiliten al usuario acceder a aquellos contenedores que interesen.

En el caso de las habitaciones y tareas es al contrario. El valor por defecto del atributo para estos casos es falso, de forma que si no existe una definición de permiso de acceso explícita en la definición de rol, no se podrá acceder a dichos recursos.

Al igual que para los contenedores, las definiciones de tipo rol son públicas por defecto. Esto tiene sentido porque en la herramienta de usuario egExplorer es posible que un usuario le asigne roles a otro usuario, siempre y cuando esos roles sean públicos. Para evitar que los usuarios puedan realizar este tipo de acciones, se recomienda que los roles se definan tambien como privados (dando valor falso al atributo), dejando la asignación de roles exclusivamente para la herramienta de gestión egAdmin.

Ejemplo

• Veamos ahora un caso práctico que trata los tipos abstractos, la herencia y la redefinición de permisos para que queden reflejados los conceptos que hemos estudiado a lo largo de este artículo:

tipo abstracto [Permisos comunes] es rol    //rol que no podrá ser asignado a ningún usuario

    accede [Libro de entrada]: abrir;
    accede [Libro de salida]: abrir;
    accede [Fichero de terceros]: abrir;
    accede [Registro de documentación]: abrir;
    accede [Expedientes de beca]: abrir;
    accede [Fichero de trabajadores]: abrir;
    accede [Oficina de recursos comunes]: entrar;

fin

tipo [Usuario Oficina del Registro] es [Permisos comunes]   //rol que hereda los permisos del rol "Permisos comunes"

    -publico = falso;

    accede [Entrada]: crear;
    accede [Expediente de beca]: crear;
    accede [Salida]: crear;
    accede [Tercero]: crear;
    accede [Requerimiento de documentación]: crear;
    accede [Oficina de recursos comunes]: Sin_Acceso; //redefinimos el permiso heredado
    accede [Registro de entrada y salida]: entrar;

    realiza [Registrar entrada]
    realiza [Elaborar requerimiento]
    realiza [Firmar requerimiento]
    realiza [Registrar salida de documentación]

    firma [Requerimiento de documentación]:[Datos generales].[Firma del escrito];

fin

Jerarquía en los permisos

Cuando en un determinado centro existe un usuario con más de un rol asignado, es posible que en cada uno de ellos exista el mismo permiso pero con niveles de acceso diferentes. En estos casos, prevalece el permiso menos restrictivo. Es decir, si tenemos un permiso "abrir" y otro "crear" sobre una misma definición de contenedor, prevalecerá el permiso "crear".

Otra contradicción que se puede dar es tener una definición de contenedor pública, y en un rol determinado tener asociado a esa definición de contenedor el acceso "Sin_Acceso". La norma en estos casos es que el atributo público siempre prevalece sobre los permisos cuando tiene valor verdadero. Si tenemos una definición Expediente como público, y un usuario tiene un rol que incluye el nivel de acceso "Abrir" sobre esos objetos, prevalecerá el carácter público de la definición y por tanto podrá abrir, modificar y crear objetos de ese tipo, aunque el permiso solo le deje abrirlos.

Por el contrario, si los recursos no son públicos, se tendrá en cuenta el permiso asociado a ellos.

Crear un superusuario

Es posible que además de definir los roles para cada tipo de usuario nos interese crear un "superusuario" que tenga acceso a todos los recursos del centro, bien para nosotros hacer pruebas en el centro como desarrolladores, o bien por petición del cliente. Para ello, tendríamos que crear un rol e incluir un permiso por cada definición de contenedor, habitación o tarea que exista en el centro, algo que resultaría bastante tedioso.

Existe una forma de asignar permisos de una forma genérica sobre un recurso determinado. Simplemente poniendo la palabra reservada <<accede>> seguida del recurso en cuestión. Su sintaxis sería la siguiente:

tipo [Superusuario] es rol

    -publico = falso;

    accede contenedor

    accede habitacion

    accede tarea

fin

Por tanto, los usuarios que tengan asignados este rol podrán acceder a todos los objetos, a todas las habitaciones, y realizar todas las tareas del sistema de información.

En el caso de las firmas, esta opción no está disponible, de forma que tendríamos que asignar esos permisos como lo habíamos hecho hasta ahora, uno por uno.