Gestion dynamique des rôles avec Spring security

Bonsoir,

Je veux savoir s'il est possible de gérer les rôles des utilisateurs et les accès aux URL de façon dynamique avec le framework spring security.

Par exemple : je veux crée un rôle ROLE_MANAGER (l'administrateur de l'application celui qui crée les rôles). Ce rôle peut modifier/lire par exemple la liste des utilisateurs.
Donc, il a l’accès aux URL suivants: "localhost:8080/App/getAllUsers" + "localhost:8080/App/UpdateUsers"

On peut faire cet exemple dans spring security sans besoin de définir de manière statique les URL et ses rôles comme ceci:

Code:

---

1 2 3 4

http.authorizeRequests().antMatchers("/App/getAllUsers").hasRole("MANAGER") .and() ... ..antMatchers("/App/UpdateUsers").hasRole("MANAGER")

---

Merci de m'orienter vers la bonne solution,

Personnellement, je ne joue jamais avec le hasRole() de la couche Web pour diverses raisons,
je définis autant de WebSecurityConfigurerAdapter que de méthodes d'authentication supportée par l'application et conduisant à des "zones" d'URL particulières et des politiques de csrf(), sessionManagement(), ... différentes.

Exemple de cas simple avec 2 WebSecurityConfigurerAdapter:
un premier supportant le BASIC AUTH pour les REST services sur l'espace /rest (pas de csrf et session STATELESS)
et un deuxième pour l'authentication via un ou plusieurs filtres JEE (CAS, OAUth2, ...) pour l'interface utilisateur, sur le reste des URLs (csrf et session fixation par migration)
(le userform login n'étant utilisé que dans la config des tests unitaires)

j'utilise juste le ".authenticated()" sur les antMatchers() qui doivent être protégés par authentication (la majorité).

La "vraie" protection se fait un niveau de la couche service avec les annotations @Secure, @PreAuthorize, ... de Spring ou celles de la JSR-250.

Les avantages que j'y trouve étant :
- configuration de sécurité identique dans toutes les applications : le "credential manager" étant ici identique pour toutes les applis, seuls les paramètres pour s'y connecter (essentiellement l'ID de l'application client) changent
le "credential manager" == le service (application indépendante) qui pour un utilisateur donné et une application client retourne les "authorities" (les rôles)
- la manière de retourner les erreurs est standardisée puisque les "problèmes" d'autorité arrivent toujours dans la même couche (et la manière de les logger/notifier aussi...)
- la couche service reste protégée quelque soit la manière d'y accéder (MVC, batch, Quartz, ...)
- on minimise le nombre d'endroits où l'on s'occupe de la gestion des "authorities"