El Modelo de Autorización: Authorities vs. Roles
Una vez que el usuario está autenticado, Spring Security examina sus privilegios para determinar si tiene autorización para interactuar con las rutas o métodos del sistema.
Todo privilegio en Spring Security se representa mediante la interfaz GrantedAuthority. Sin embargo, a nivel de diseño se diferencian dos enfoques clave:
1. Authorities (Permisos Puntuales / Acciones)
Representan acciones específicas o permisos atómicos sobre entidades del dominio. Definen con precisión quirúrgica qué puede ejecutar el usuario:
- Ejemplos:
READ,WRITE,DELETE_USER,EXPORT_REPORT. - En la configuración de rutas o anotaciones se verifican mediante
hasAuthority():.requestMatchers(HttpMethod.DELETE, "/mvc/users/**").hasAuthority("DELETE_USER")
2. Roles (Perfiles Organizacionales / Cargos)
Representan perfiles de usuario de alto nivel que suelen agrupar un conjunto de authorities.
- Ejemplos: Administrador, Gerente, Cliente, Vendedor.
- La Convención del Prefijo
ROLE_: En Spring Security, un rol es técnicamente unaGrantedAuthoritycuyo nombre comienza con el prefijoROLE_(ej.ROLE_ADMIN,ROLE_USER). - Al verificar un rol mediante
hasRole("ADMIN"), Spring Security añade automáticamente el prefijoROLE_por debajo:// Ambas expresiones evalúan exactamente lo mismo:.requestMatchers("/mvc/admin/**").hasRole("ADMIN").requestMatchers("/mvc/admin/**").hasAuthority("ROLE_ADMIN")
3. Buenas Prácticas de Diseño en Sistemas Complejos
En arquitecturas empresariales maduras, los usuarios se vinculan a Roles, y cada Rol tiene asignada una lista de Permisos (Authorities) en la base de datos relacional.
De esta forma, si cambian los permisos asignados a un rol, la configuración se ajusta dinámicamente en las tablas de la base de datos (roles, permissions, role_permissions) sin tener que modificar ni recompilar el código fuente Java de la aplicación.