En respuesta a su primera pregunta, el mayor problema con la comprobación de que un usuario tiene un rol en lugar de un permiso específico, es que los permisos pueden tener múltiples roles. Como ejemplo de esto, un desarrollador podría tener acceso para ver el portal del desarrollador en la intranet de la compañía, que probablemente también sea un permiso de su gerente. Si un usuario intenta acceder al portal del desarrollador, tendrá una verificación similar a:
if(SecurityUtils.hasRole(developer)) {
// Grant them access to a feature
} else if(SecurityUtils.hasRole(manager)) {
// Grant them access to a feature
} else if...
(Una switchdeclaración en su idioma de elección sería mejor, pero aún no particularmente ordenada)
Cuanto más común o más extendido sea un permiso, más roles de usuario necesitará verificar para asegurarse de que alguien pueda acceder a un sistema determinado. Esto también llevaría al problema de que cada vez que modifique los permisos para un rol, necesitaría modificar la verificación para reflejar esto. En un sistema grande, esto se volvería muy difícil de manejar muy rápidamente.
Si simplemente verifica que el usuario tiene el permiso que le permite acceder al portal del desarrollador, por ejemplo, no importa qué rol tenga, se le otorgará acceso.
Para responder a su segunda pregunta, la razón por la que tiene roles es porque actúan como fáciles de modificar y distribuir "paquetes" de permisos. Si tiene un sistema que tiene cientos de roles y miles de permisos, agregar un nuevo usuario (por ejemplo, un nuevo gerente de Recursos Humanos) requeriría que lo revise y les otorgue todos los permisos que tienen otros gerentes de Recursos Humanos. Esto no solo sería tedioso, sino que es propenso a errores si se hace manualmente. Compare esto con simplemente agregar el rol de "gerente de recursos humanos" al perfil de un usuario, lo que le otorgará el mismo acceso que cualquier otro usuario con ese rol.
Podría argumentar que podría simplemente clonar un usuario existente (si su sistema lo admite), pero si bien esto le otorga al usuario los permisos correctos para ese momento, puede ser posible que intente agregar o eliminar un permiso para todos los usuarios en el futuro. difícil. Un escenario de ejemplo para esto es si quizás en el pasado el personal de recursos humanos también estaba a cargo de la nómina, pero más tarde la compañía se vuelve lo suficientemente grande como para contratar personal específicamente para manejar la nómina. Esto significa que RR.HH. ya no necesita acceder al sistema de nómina, por lo que se puede eliminar el permiso. Si tiene 10 miembros diferentes de RR. HH., Deberá hacerlo manualmente y asegurarse de eliminar el permiso correcto que introduce la posibilidad de error del usuario. El otro problema con esto es que simplemente no escala; A medida que gana más y más usuarios en un rol determinado, la modificación de un rol es mucho más difícil. Compare esto con el uso de roles, donde solo necesitaría modificar el rol general en cuestión para eliminar el permiso, lo que sería reflejado por cada usuario que tenga ese rol.