... | ... | @@ -7,3 +7,15 @@ Keycloak propose plusieurs fonctionnalités qui pourraient servir dans ce but : |
|
|
* Service d'autorisation (resource server): https://www.keycloak.org/docs/latest/authorization_services/
|
|
|
Permettrait de définir des ressources de type groupe, et d'assigner des permissions à l'utilisateur sur celles-ci. Nécéssite de requêter le serveur d'autorisation depuis l'application.
|
|
|
|
|
|
|
|
|
Solution en cours de développement :
|
|
|
|
|
|
* à l'initialisation du serveur, un groupe 'admins' est créé si non existant
|
|
|
* lorsqu'un groupe 'toto' est créé dans la boite, on crée automatiquement les groupes suivants dans Keycloak : 'member_toto', 'animator_toto' et 'admin_toto' (realm) ainsi que des rôles du même nom (dans le client laboite)
|
|
|
* lorsqu'un rôle sur un groupe est ajouté/supprimé dans laboite, on ajoute/enlève le groupe correspondant dans Keycloak
|
|
|
* Rqe: en modifiant le tokenClaimName des mappers du scope 'roles' dans Keycloak, on peut controller le nom de l'attribut qui recevra les roles de l'utilisateur à la connexion.
|
|
|
|
|
|
Problèmes restants:
|
|
|
* Pour l'instant le mapping des rôles sur les groupes ne semble pas fonctionner à travers l'API. cf [ce bug report](https://issues.redhat.com/browse/KEYCLOAK-14598)
|
|
|
* le client développé effectue une authentification pour récupérer un token à chaque création de groupe / affectation de roles. Mettre en place un cache de l'access_token et du refresh_token et les utiliser correctement (prise en compte expiration et rafraichir tant que le refresh_token est valide)
|
|
|
|
|
|
\ No newline at end of file |