Actualmente una área del equipo de desarrollo esta avanzando con la aplicación vAdmin, responsable de la administración del vServer. Como podéis ver el esquema adjunto vAdmin se conecta desde cualquier ubicación por VATP hasta el vServer. Esta posibilidad nos permitirá administrar cualquier servidor de manera remota.
Entre los paramentros administrables desde el vAdmin se encuentra la gestión de permisos, que en esta ocasión debe contemplar los permisos de edición, ejecución y traducción entre otros.
Uno de los objetivos principales de vAdmin es que puediera ofrecer la máxima flexibilidad para cubrir todos los casos en la implantación y desarrollo de aplicaciones, pero esta flexibilidad no podria ir acompañada de una gestión compleja de permisos en grupos, usuarios, cajas, sitios, servidores, máquinas, etc.
El diseño de permisos se ha centrado en dos puntos, Sitios y Grupos.
Los permisos se asignarán directamente en los grupos, ayudando a conseguir una organización estructurada de estos. Un usuario pertenece a unos grupos y la suma de los permisos de sus grupos componen los permisos particulares de dicho usuario.
El caso extremo que puede suceder es que se necesite un grupo por cada usuario, siempre y cuando cada usuario necesite permisos específicos y no acumulables entre grupos.
Actualmente desestimamos la posibilidad de que existan permisos para cada usuario ya que el esfuerzo de configuración es el mismo y la flexibilidad y reutilización es mucho mayor.
Como usuarios experimentados de las versiones anteriores de la plataforma, nos gustaría conocer si este sistema de permisos basado en los grupos cubren todas las necesidades en la implatación de vuestras soluciones.
Es importante recordar que en este caso tambien con el VCL (Velneo Class Library), se podran añadir soluciones externas que permitirán importar, exportar o sincronizar nuestra lista de usuarios con bases de datos de usuarios ( LDAP, Active Directory, etc. ).
Etiquetas: gestion usuarios, permisos, privilegios
- Valorar esta entrada
(Sin votos) - Comentarios (9)
- Comentar
- Imprimir
Por fjpnovo #
Buenas tardes:
A priori (y sin haberlo pilotado) yo diría que si, ya que es un sistema similar al utilizado en la gestión de usuarios de Windows. Esta organización de permisos por grupos se utiliza en multitud de aplicaciones y escenarios en el entorno Windows y va bien.
Un saludo,
Fran.
Por eic #
Efectivamente, el control por grupos puede resolver todos los escenarios posibles (en el peor de los casos, habría que crear un grupo por usuario, como se comenta). Sin embargo, y aunque esta puede ser una buena solución momentánea, pienso que a largo plazo se podría implementar también por usuario. La primera opción (sólo por grupos) permite una mayor reutilización, pero la mayor flexibilidad la da una gestión por usuarios. Pero como se suele decir, “funcionar funcionaría”.
Por otro lado, pienso que la integración con algunas bases de datos de usuarios (sobre todo con las más comunes, como es Active Directory) podría plantearse como algo estandar, no como una solución externa. Necesitaría un cierto análisis (quizá una opción “Utilizar grupos de usuarios de Windows” y permitir seleccionar esos grupos desde las pantallas de configuración, como en SQL Server), pero sería de gran ayuda. Por supuesto, no cubriría todos los casos (seguro que hay situaciones en que esto no es suficiente) pero cubriría las necesidades en muchos casos, en los que de modo estandar puedes ofrecer al cliente que sus usuarios no tienen que autenticarse en la aplicación, sino sólo contra su servidor de dominio.
Por lo demás, administrar el servidor de forma remota (sin herramientas de control o similares) es uno de los sueños de cualquier programador en Velázquez.
Saludos,
Fran Varona
Por rorts #
En principio el sistema de permisos basado en grupos y sitios me parece suficiente, siempre que el numero de grupos no tenga maximo, ya que de normal no es el caso, pero para el caso en que cada usuario tenga que tener unos permisos diferentes, de forma un poco mas ilogica se podria resolver tambien, con lo cual todos los casos se ven contemplados, desde los habituales hasta los mas inusuales
Por daniel #
cuando hablamos de permisos. yo entiendo que hay premisos en dos sentidos, ha quien se le da permiso y que permiso tiene.
si estamos hablando de permisos de cara al usuario me parece suficiente,pero de cara a los permisos que tiene digamos de ejecucion, lectura, … quedarnos en sitios me parece poco.
Por tecnico #
Para mi, lo ideal, aunque representaría un poco mas de trabajo para vosotros en desarrollo, sería dar la posibilidad de definir propiedades por grupo de usuarios, que sean heredables por los usuarios.
Los usuarios, de esta forma podrían heredar todas las propiedades de su grupo, pero permitiéndonos definir algunas excepciones (cambiar solo las propiedades que nos interese, manteniendo el resto con el valor definido en su grupo).
Además no tenemos que olvidar los estilos y el menú inicial. Nos puede interesar cambiar el estilo y menú inicial solo por usuario, aunque resto de los parámetros del grupo sea el mismo. En caso contrario, nos obligaría a definir un nuevo grupo para cada cambio de estilo / menú inicial. Por ejemplo en el caso de una aplicación que tenga 3 menús y 5 estilos, me obligaría a crear 15 grupos para contemplar todas las posibilidades.
Saludos,
José Luis Cuesta
Por jcmar #
Todo esto es muy interesante.
Entiendo que un usuario pertenece a grupos y estos se le da los permisos. Bien. Me parece sencillo y potente.
La posibilidad de interactuar con LDAP es importantísisma, ya que esto es un estandar.
Por otro lado, está incluida la posiblididad de gestionar el vServer desde programación al estilo de los script de SO?.
Se me plantean varios escenarios:
1.- Se puede crear una aplicación para la gestión de la aplicación del cliente sin que este tenga que administrar el servidor?.
2.- Que desde la propia aplicación se pueda gestionar a los usuarios sin necesidad de acceder al servidor?.
3.- Una aplicación para instalar otra aplicación y sus usuarios (automatizar la instalacion de aplicaciones)
Saludos
Por davidgu #
Muchas gracias por vuestras aportaciones.
Del mismo modo que el resto de la plataforma lo principal en nuestro trabajo actualmente es el VCL, que son todas las funciones que gestionan nativamente las funcionalidades de la plataforma.
En este caso VCLClientAdmin es la librería que se ocupa de esta tarea. Contiene todas las funciones que administran el servidor y en este caso el vAdmin es la única aplicación capaz de atacar a esta librería.
Podemos de una forma relativamente sencilla implementar importadores de bases de usuarios externas ( LDAP, Active Directory, etc ).
Como os podéis imaginar esto no es una prioridad ya que herramientas externas pueden surgir a millones, la prioridad es que se puedan hacer usando el API del VCL.
Del mismo modo que queremos que se use nuestro API VCL, que mejor que usar Velneo para realizar esas aplicaciones que administran servidores. Nuestra intención es que muchas de las funciones de administración puedan estar nativamente para su uso en los procesos o funciones y de esta manera cualquier desarrollador en Velneo podría realizar una aplicación web para gestionar un vServer, por ejemplo.
Para explicarlo de otra forma, para que vamos a daros solo el Pez ( vAdmin ) si podemos daros la caña de pescar (VCL).
En nuestro caso os damos un pez y la caña de pescar
Saludos
Por correo #
Ahora cada vez que conectamos con un servidor de Velezquez, este muestra todas las aplicaciones y luego pide la autenticación del usuario.
Creo que esto debería ser justo al contrario, cuando un usuario quiere conectar con un servidor de Velazquez debería primero autenticarse y luego el sistema devolverle el menú de aplicaciones para las cuales esté autorizado, teniendo en cuenta los permisos a cada aplicación y el rango de ip”s desde el que puede conectar.
Un Saludo
Florentino Moreno
Flyp Software
Por comercial #
Que interesante sería que se pudieran gestionar los permisos a nivel de tabla de base de datos y si me apuras a nivel de campo.