• Cómo funciona UserRole

  • OpenKM tiene muchas características interesantes, pero es necesario un proceso de configuración para mostrar todo su potencial.
OpenKM tiene muchas características interesantes, pero es necesario un proceso de configuración para mostrar todo su potencial.
Forum rules: Por favor, antes de preguntar algo consulta el wiki de documentación o utiliza la función de búsqueda del foro. Recuerda que no tenemos una bola de cristal ni poderes mentales, o sea que que para informar sobre un error es necesario que nos indiques tanto la versión de OpenKM que usas como la del navegador y sistema operativo. Para más información consulta Cómo informar de fallos de forma efectiva.
 #12157  by ccbaxter
 
Hola a todos,

No me aclaro con el tema de los "roles"...A ver si alguien me lo puede explicar un poco.

Según he leído, el "UserRole" es obligatorio para todos los usuarios porque si no lo tienen no se pueden loguear, hasta aquí bien. Por otra parte, parece que es recomendable quitarlo del raíz "okm:root" para que no se propague por toda la taxonomía, ya que todos los usuarios lo tienen. Vale.

Sin embargo, si se quita del raíz y se sustituye por otro, todos los usuarios necesitan tener ese NUEVO rol para poder entrar. Entonces... ¿qué sentido tiene quitar UserRole del raíz, porque lo tienen todos los usuarios, si hay que sustituirlo por uno que también lo tienen que tener TODOS los usuarios?. No lo pillo, creo que me estoy perdiendo algo....

Alguién me lo explica, please.

Gracias.
 #12185  by pavila
 
Vale, una cosa es el rol necesario de conexión a la aplicación OpenKM y otra son los permisos de las carpetas y documentos:

- El primero está definido en el fichero web.xml. Por tanto, es necesario que un usuario tenga el rol UserRole asignado para poder entrar en la aplicación.

- El otro cometido de los roles es delimitar el acceso a un documento o carpeta. Por ese motivo, si todos los documentos tienen permisos de lectura para el rol UserRole, no habrá forma de restringir el acceso.

No sé si me he explicado bien.
 #12194  by ccbaxter
 
Ok, eso es lo que suponía. Pero entonces no es correcto lo que he leído en otros hilos sobre eliminar el UserRole de "okm:root" porque si se elimina ningún usuario puede loguearse ¿no?. Y eso obliga a ir quitándolo individualmente en cada carpeta, porque como parece lo hereda del raíz cuando se crea. ¿ es así ?

Un saludo y gracias por contestar.
 #12216  by jllort
 
La idea es que en el usuario tenga UserRole y RoleX lo que haces en los nodos principales root, categories, templates es eliminar el UserRole y dar acceso de lectura al RoleX ( esto es lo mas nomal )
 #12229  by ccbaxter
 
Vale, pero yo tengo algunos usuarios a los que me gustaría dar acceso únicamente a una carpeta del repositorio. Si tengo que dar permiso de lectura al RoleX en el raíz okm:root, cada carpeta nueva que añado tendrá permiso de lectura para el RoleX y como el usuario tiene que tener ese role porque si no lo tiene, no puede loguearse, eso me obliga a eliminar los permisos de lectura carpeta a carpeta (bueno en realidad eliminar el RoleX heredado del raíz)

Por eso digo que no entiendo lo de eliminar el UserRole del nodo principal si luego tengo que sustituirlo por otro que tiene permiso de lectura para un Role que también tienen que tener TODOS los usuarios. ¿ Eso no sería lo mismo que dejar sólo el permiso de lectura al UserRole en el raíz?

No se si ahora ha quedado más claro....
 #12274  by jllort
 
No hombre no. Son cosas distintas.
Todos los usuarios tienen que conectar con OpenKM para eso todos tienen que tener el UserRole.
Pero no todos los usuarios comparten los mismos roles, lo que no interesa bajo ningun concepto es propagar el UserRole por el repositorio, por que eso "por error" lo que te hará es que todos los usuario tengan privilegios ahí. Por eso aconsejamos que ese rol se sustituya por los roles de los usuarios, eso obliga a tener un mayor control, evidentemente puedes propagar un rol por error, pero nunca será tan catastrófico como propagar un rol que tienen todos los usuarios obligatoriamente. Igual en tu entorno da igual, pero en entornos de alta seguridad tiene que ser así.
 #12322  by ccbaxter
 
A riesgo de ser reiterativo, lo intentaré una vez más. Aunque ya no se muy bien cómo explicarlo y por favor, no me volváis a decir que "el UserRole es necesario para loguearse en la aplicación y que otra cosa distinta son los permisos que se aplican en las carpetas usando los Roles como grupos" , eso creo que ya ha quedado claro.

A ver si con un ejemplo nos entendemos...

Estado inicial:

okm:root

Grupo: UserRole
Permisos: Lectura (SI) Escritura(SI) Borrado (SI) Seguridad(SI)

Usuario: cliente1
Rol: UserRole
El usuario "cliente1" puede loguearse y ver la taxonomía sin problemas, tiene acceso a cualquier carpeta con permisos de lectura (como mínimo) para el grupo "UserRole".
Segundo estado:

okm:root

Sustituímos el grupo "UserRole" por uno nuevo de nombre "BaseRole"

Grupo: UserRole --> Eliminado

Grupo: BaseRole
Permisos: Lectura (SI) Escritura(SI) Borrado (SI) Seguridad(SI)

Usuario: cliente1
Rol: UserRole
Si dejamos al usuario "cliente1" sólo con "UserRole" NO puede entrar en la aplicación porque no tiene permisos de lectura sobre "okm:root". Los errores son del tipo:

OKM-012015(GetRootFolder): La ruta del no existe
okm:root
OKM-022001(GetEnabledExtensions): OKM-022001
okm:root okm:root
OKM-014001(GetUserWorkspace): Error interno del repositorio
Por tanto no es suficiente con el usuario tenga el "UserRole" para poder entrar en la aplicación, también necesita permisos de lectura en el raíz

Tercer estado:

Añadimos al usuario "cliente1" al grupo "BaseRole"

Usuario: cliente1
Rol: UserRole BaseRole

Ahora el usuario puede loguearse y tiene acceso a cualquier carpeta con permiso de lectura (como mínimo) para el grupo "BaseRole" y/o "UserRole"
Como cada carpeta nueva creada bajo "okm:root" tiene permisos de lectura para "BaseRole" el usuario tiene acceso a ella hasta que se elimine ese permiso y ésto nos lleva a mi premisa inicial:

¿Para qué he quitado "UserRole" de "okm:root" y lo he sustituído por "BaseRole" si ahora tengo que asignar permisos individualmente sobre cada carpeta nueva creada, exactamente igual que si hubiera dejado "UserRole" en "okm:root" ?
Y repito que todo esto surge porque estoy buscando la forma de que determinados usuarios (clientes externos) tengan acceso únicamente a unas carpetas específicas y el resto no deberían verse en la taxonomía.

Si la solución pasa por configurar permisos de forma individual en cada carpeta me podría haber ahorrado el post, sólo comentar que me parece más práctico un sistema de DENEGACIÓN por defecto y no al revés.

(perdón por la extensión del post, espero que ahora se entienda...)
 #12351  by jllort
 
Hombre por que para esto se crea mas de un role

usuario_otros -> tiene UserRole y OtrosUsuariosRole
usuario_1 -> tiene UserRole y ExternosRole
usuario_2 -> tiene UserRole y ExternosRole

okm:root ( acceso a ExternosRole / OtrosUsuariosRole -> unicamente acceso de lectura )
okm:root/carpeta otros ( acceso RW unicamente para OtrosUsuariosRole )
okm:root/externos ( acceso solo lectura a ExternosRole )
okm:root/externos/usuario 1 ( acceso RW solo para usuario 1 )
okm:root/externos/usuario 2 ( acceso RW solo para usuario 2 )

Nota: La idea es jugar con varios roles para los sitios generales y restringir hasta nivel de usuario ahí donde haga falta. Lo suyo es crearlo bien desde el principio y así cuando vas creando la estructura de carpetas los privilegios ya se van propagando como toca en el nodo okm:root solo debería poder crear carpetas un superusuario.

About Us

OpenKM is part of the management software. A management software is a program that facilitates the accomplishment of administrative tasks. OpenKM is a document management system that allows you to manage business content and workflow in a more efficient way. Document managers guarantee data protection by establishing information security for business content.