Construction d'un serveur d'autorisation Java OAuth2.0 avec Keycloak
TL; DR
- Objectif: serveur d'autorisation Java:
- Flux d'octroi de code d'autorisation OAuth2.0 avec des autorisations affinées (pas un simple serveur SSO)
- Gestion des utilisateurs et authentification: base de données personnalisée
- Gestion des clients et authentification: Keycloak
- Questions: Quelles sont les meilleures pratiques pour implémenter un serveur d'autorisation Java avec une gestion des autorisations applicatives sauvegardée sur Keycloak?
- Quel adaptateur/API Keycloak dois-je utiliser dans mon développement?
- Comment les utilisateurs devraient-ils être gérés/apparaître dans KeyCloak s'ils doivent apparaître du tout?
Avertissement
Je suis assez débutant avec Keycloak et, bien que je pense en comprendre les principes principaux, il semble être un outil précieux et je crains de ne pas pouvoir encore me tromper sur certains aspects de la meilleure façon de l'utiliser. S'il vous plaît n'hésitez pas à me corriger.
Le contexte
Nous envisageons de mettre en place une API obligeant nos utilisateurs (ci-après "utilisateurs") à accorder des autorisations à des applications tierces (ci-après "clients").
Nos utilisateurs sont stockés dans un système de gestion des utilisateurs basé sur une base de données existante et personnalisée. Pour nos clients, nous envisageons d’utiliser Keycloak .
Le consentement des utilisateurs sera donné via un flux d'octroi de code d'autorisation OAuth2.0. Ils se connecteront, spécifieront les autorisations qu'ils accorderont et celles qu'ils refuseront, puis le client récupérera le jeton d'accès qu'il utilisera pour accéder à l'API.
D'après ce que j'ai compris, Keycloak peut gérer le jeton d'autorisation, mais il ne devrait rien connaître de ce qui est applicatif, ce que nos autorisations sont. En conséquence, j'ai envisagé de créer un serveur d'autorisations personnalisé qui utilisera Keycloak pour tous les problèmes d'identité/d'authentification mais gérera lui-même les autorisations applicatives.
Ensuite, nous utiliserons Keycloak pour l’authentification du client et le code d’autorisation/gestion des jetons d’accès, et une partie applicative vérifiera les autorisations.
Problème
En plus de mes premières expériences, je navigue sur Internet depuis une semaine maintenant et je suis surpris de voir que ce serait un cas assez classique. Pourtant, j'ai trouvé presque rien, alors je ne cherche peut-être pas correctement.
J'ai trouvé de nombreux tutoriels Spring/Spring Boot1 sur la façon de faire un "serveur d'autorisation simple". Ce sont principalement des serveurs SSO, et peu d’entre eux gèrent les autorisations, à l’exception de ceux mentionnés dans this SO answer2. Je pense que nous pouvons nous en occuper.
Le vrai problème que je rencontre et qu'aucun des tutoriels que j'ai trouvés ne traite est le suivant:
Comment intégrer Keycloak dans ce serveur d'autorisations?
J'ai jeté un coup d'œil aux adaptateurs Java disponibles . Ils ont l'air OK en ce qui concerne l'authentification, mais je n'ai pas vu d'indications sur la gestion des clients à partir d'un serveur d'autorisation personnalisé (c'est-à-dire, administrer le domaine).
J'ai donc suppose que je devrais utiliser l'API admin . Suis-je correct et est-ce une bonne pratique? Je n'ai vu aucun adaptateur pour cela, donc je suppose que je devrais alors utiliser l'API REST.
Je me demande aussi comment intégrer nos utilisateurs dans le design? Doivent-ils être dupliqués à l'intérieur de Keycloak? Dans ce cas, devrions-nous utiliser l'API d'administration de Keycloak pour transférer les données du serveur d'autorisation ou existe-t-il un meilleur moyen?
Enfin, me manque-t-il un autre point évident?
Désolé pour le long message et les nombreuses questions, mais tout se résume à une question à la fin:
Quelles sont les meilleures pratiques lors de la création d'un serveur d'autorisation utilisant Keycloak comme réseau fédérateur?
1. Quelques exemples: Tutoriel Spring Boot OAuth2 - Un article de blog - Un autre article de blog
2. Je me suis principalement concentré sur l'exemple d'application fourni par Spring Security OAuth
Construction d'un serveur d'autorisation Java OAuth2.0 avec Keycloak
C'est possible, mais c'est un peu compliqué et il y a beaucoup de choses qui doivent être personnalisées.
Vous pouvez tirer une motivation de repo inférieur.
keycloak-delegate-authn-consent
Construction d'un serveur d'autorisation Java OAuth2.0 personnalisé avec MITREid
Si vous êtes prêt à utiliser d'autres implémentations d'Oauth et d'OIDC, je peux vous suggérer MITREid, qui est une implémentation de référence d'OIDC et pourrait être personnalisé dans une large mesure.
J'ai moi-même utilisé cette exigence pour la rendre similaire à la vôtre et il est hautement personnalisable et facile à mettre en œuvre.
https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server
MITREid Connect utilise Spring Security pour son authentification, vous pouvez donc insérer le composant de votre choix dans cet espace. Il existe de nombreuses ressources utiles sur le Web concernant la rédaction et la configuration de filtres Spring Security pour les mécanismes d'authentification personnalisés.
Vous voudrez regarder le fichier user-context.xml pour savoir où l'authentification de l'utilisateur est définie. Dans le projet principal, il s’agit d’un simple champ nom d’utilisateur/mot de passe par rapport à une base de données locale. Dans d'autres, comme le projet de superposition LDAP, cela se connecte à un serveur LDAP. Dans certains systèmes, comme le serveur "oidc.mit.edu" du MIT, il existe en réalité une poignée de mécanismes d'authentification différents pouvant être utilisés en parallèle: LDAP, Kerberos et certificats dans ce cas.
Notez que dans tous les cas, vous devrez toujours avoir accès à un magasin de données UserInfo quelque part. Cela peut provenir de la base de données, de LDAP ou de quelque chose d'autre, mais il doit être disponible pour chaque utilisateur connecté.
Le serveur MITREid Connect peut fonctionner simultanément en tant que fournisseur d'identité OpenID Connect (IdP) et serveur d'autorisations OAuth 2.0 (AS). Le serveur est une application Spring et ses fichiers de configuration se trouvent dans openid-connect-server-webapp/src/main/webapp/WEB-INF/et se terminent par le format .xml. La configuration a été divisée en plusieurs fichiers .xml pour faciliter les remplacements et la configuration personnalisée.