Aplicación con diferentes permisos por Tipo de usuario

Este tutorial podria servirte:

Para saber mas te sugiero comprar este libro: Spring Security

Si no estás usando Spring (que sería lo mejor) puedes checar el tutorial de Oracle al respecto.

Gracias por las respuestas, pero lo que busco es para una aplicación de escritorio... por lo que esto no me valdría, no?

Para desktop.
Si necesitas usar sesiones de usuario como en aplicación web, podrías echarle un vistazo a Apache Shiro.

Federico:

Se puede hacer de la siguiente forma:

1.- Debes de crear diferentes usuarios en tu BD.
2.- Debes de crear, también diferentes roles (Administrador, gerente, usuario normal, etc).
3.- Debes de asignarle roles a los usuarios.
3.- Al momento de iniciar sesión debes de pedir nombre de usuario, contraseña y rol. En base a este último parámetro podrás saber que partes de tus menú o contenido puede ser visto por dicho usuario.

Ignoro que base de datos estés utilizando (no lo mencionas), pero aplicar dicha solución en una base de datos Interbase/Firebird se convierte en algo trivial. Suponiendo que estás utilizando MySQL, tengo entendido que puedes crear diferentes usuarios y roles, para asignar privilegios a los objetos de tu base de datos (por cierto, nunca he visto un tutorial en internet que haga algo parecido. Siempre he vista esa nefasta y mala práctica de crear una tabla de usuarios e iniciar sesión como ROOT y desde ahí "validar" al usuario con el que estás entrando. Aunque al final de cuentas sigues firmado como ROOT). Esta mala práctica es un hueco de seguridad para la inyección de SQL.

Por otro lado, si en un momento te interesa saber como hacerlo en Interbase/Firebird házmelo saber y podemos hacer un pequeño ejemplo.

Saludos,
Gerardo Suárez Trejo

PD. Cosa curiosa, tiene nombre de un famoso desarrollador mexicano de software libre (Federico Mena Quintero), bueno en realidad no se tu segundo apellido. Saludos nuevamente ...

...Suponiendo que estás utilizando MySQL, tengo entendido que puedes crear diferentes usuarios y roles, para asignar privilegios a los objetos de tu base de datos (por cierto, nunca he visto un tutorial en internet que haga algo parecido. Siempre he vista esa nefasta y mala práctica de crear una tabla de usuarios e iniciar sesión como ROOT y desde ahí "validar" al usuario con el que estás entrando. Aunque al final de cuentas sigues firmado como ROOT). Esta mala práctica es un hueco de seguridad para la inyección de SQL....

Sería bien interesante un ejemplo de lo que acabas de mencionar, interesante porque en todos lados encuentras los esquemas de la forma que describes como "mala práctica", a mí en lo personal (y estoy seguro que a la comunidad también) me gustaría ver cómo desarrollas un ejemplo, incluyendo por supuesto cómo podrías inyectar SQL.

Saludos.

Qué tiene que ver la inyección de SQL con el usuario que se utilice para entrar a la base de datos?

La respuesta es: NADA.

Sin embargo, el tener distintos usuarios, cada uno sólo con los privilegios que necesita, aminora el daño que se puede hacer si la aplicación tiene vulnerabilidades de inyección de SQL.

Esa nefasta y mala práctica de crear la tabla de usuarios es la única opción para aplicaciones web donde la gente se auto-registra, o para aplicaciones multi-capa donde la aplicación que usa el cliente (sea en escritorio o dispositivo móvil o página web) no tiene acceso directo a la base de datos.

neko069:

Ok, me parece buena idea realizar un proyecto así. Déjame pensar en un pequeño ejemplo en forma de "tutorial". Incluso, me gustaría hacer un "screencast" (para mi gusto, es mucho mejor que la publicación de un "tutorial" escrito). Pero ...

Dos cosas:
1) Debido a mi nula experiencia en MySQL, lo realizaría en Interbase/Firebird (además creo que sería un magnífica oportunidad para promocionar dicha BD, [no hay licencias duales, ni nada de esas "cosas raras"]), y que más programadores tengan la oportunidad de que la conozcan, la evalúen y la puedan utilizar en sus proyectos venideros.
2) Como estoy en el proceso de aprendizaje de lenguaje Java, lo haría utilizando las siguientes bibliotecas (que es lo único que he aprendido hasta el momento, je, je, je ...): MyBatis + JSF + Primefaces. De esta manera, los "tiburones de la programación" nos podrán decir sus críticas, posturas, imposturas, regaños, sugerencias, etc, etc.

Bueno, díganme que piensan.

Saludos,
Gerardo Suárez Trejo

P.D. Por cierto, estoy atorado en varias cuestiones: como agregar los diferentes módulos de "SpringFramework" (para la inyección de dependencias, seguridad, y "testeo"). Seguramente Uds nos pueden echar algo de luz sobre este asunto.

@Gallo, no importa la base de datos, o los frameworks que uses, lo que importa es que ejemplifiques lo que describes, para la integración con Spring, pues hay varios tutoriales.
Ejemplo 1.
Ejemplo 2.
Ejemplo 3.
Ejemplo 4.

@ezamudio, precisamente porque me hizo ruido lo que menciona acerca de la relación de inyección de SQL con lo del usuario root y... pues lo demás, me gustaría que hiciera una demostración de lo que menciona, siempre se podrá debatir o aprender al respecto.

@ezamudio:

Cuando decía: Siempre he visto esa nefasta y mala práctica de crear una tabla de usuarios e iniciar sesión como ROOT y desde ahí "validar" al usuario con el que estás entrando. Aunque al final de cuentas sigues firmado como ROOT). Esta mala práctica es un hueco de seguridad para la inyección de SQL.

Quice dar a enterder exactamen a lo que te refieres: Sin embargo, el tener distintos usuarios, cada uno sólo con los privilegios que necesita, aminora el daño que se puede hacer si la aplicación tiene vulnerabilidades de inyección de SQL.

Tal vez si hubiera empleado el "si hay" por el "para" (Esta mala práctica es un hueco de seguridad si hay inyección de SQL), hubiera dado a entender eso mismo que tu dices (reconozco mi error y me disculpo por no haberme sabido expresar correctamente).

Bueno... siendo honestos y consecuentes con lo que se dice (y se entiede, claro está). Tu dices: Esa nefasta y mala práctica de crear la tabla de usuarios es la única opción para aplicaciones web donde la gente se auto-registra, [..] Si lees bien me refiero solo a la NEFASTA Y MALA PRÁCTICA de crear una tabla de usuarios E INICIAR SESIÓN COMO ROOT (aclaración: no grito, solo resalto lo que le da sentido a la oración para expresar lo que quiero dar a entender). No me imagino una aplicación donde la gente se auto-registre, y para hacer ese proceso, tu aplicación permita iniciar sesión como ROOT (o super usuario o usuario normal con rol de administrador, o etc). Es claro que debes crear un usuario solo con los mínimos privilegios para realizar dicha tarea ...

Saludos,
Gerardo Suárez Trejo

Ciertamente nunca debes usar el superusuario de la base de datos para tus conexiones de aplicación. Debes crear un usuario específico para la aplicación, incluso puedes tener varios usuarios para asignarlos a distintos componentes si la arquitectura de tu aplicación lo permite.

Habría que ver qué usuario utiliza esta página, donde todos los que escribimos aquí nos auto-registramos...

Gracias por los comentarios! Es una base de datos mysql, voy a ver si consigo algo. porque soy muy novato en el tema... pero de todas formas muchas gracias.

y cuál sería el correcto ejemplo de crear la clase para conectar a la base de datos dependiendo de los usuarios y permisos de la base de datos?

Hoy día podrías tener un servicio para registrar usuarios y ese puede conectarse a tu base de datos con un usuario que tenga permiso de insertar y actualizar la tabla de usuarios. Luego otro servicio para login y ese solamente puede leer y actualizar registros pero no insertar ni borrar.

Pero lo más importante es que tengas bien organizado tu código: todos los accesos de base de datos deben ser a través de componentes (modelos, si quieres llamarles así, o como sea) que permiten realizar solamente operaciones específicas.

En cuanto a los permisos, hay que tener un esquema de permisos en la base de datos, para poder asignar distintos permisos a distintos usuarios (aquí ya hablo de usuarios del sistema, no de usuarios de base de datos). Spring Security es una opción, Keycloak es otra.