Créez un domaine nommé ineat-realm (ou un nom de domaine répondant à votre besoin)
Création du domaine ineat-realm
Une fois le domaine créé, vous avez accès à la configuration complète de ce dernier.
Créer un domaine par périmètre métier permet de contextualiser les politiques de sécurités de vos applications.
Configuration du domaine ineat-realm
La configuration par défaut de la rubriqueRealm Settings de Keycloakest suffisante pour nos besoins. (consultez la documentation de référence si vous avez besoin de personnaliser la configuration)
Les actions à prévoir pour préparer la sécurisation de notre backend :
Création d’un client ineat-api, qui sera utilisé par notre projet JAVA (api) pour contacter le backend Keycloak en tant que serveur de ressources (Resource Server)
Création d’un client ineat-web, qui sera utilisé par les clients de notre API pour demander un token d’authentification à Keycloak
Création de rôles ADMIN et USER que nous utiliserons pour sécuriser nos URIs d’API (dans la partie 3 de cette série).
Création des utilisateurs possédant ces rôles, afin de pouvoir tester nos configurations
Rendez vous sur la rubrique Clients sur le menu de gauche
Cliquez sur le bouton Create à droite du tableau qui s’affiche
NOTE : Remarquez que Keycloak fournit par défaut des clients pour différents cas d’usages
Saisissez dans le champ Client ID le nom du client qui sera utilisé par votre projet back (ineat-api pour les besoins de ce tutoriel)
Cliquez sur le bouton Save afin d’accéder à la configuration du client
Configuration du client ineat-api
Le client ineat-api sera utilisé par notre projet JAVA (api) pour contacter le backend Keycloak en tant que serveur de ressources (Resource Server)
Définissez le champ Access Type à bearer-only puis valider cette configuration (bouton Save)
bearer-only
Bearer-only access type means that the application only allows bearer token requests. If this is turned on, this application cannot participate in browser logins.
Notre API sera accessible uniquement via une authentification bearer, ce qui signifie qu’avant de pouvoir la contacter, nous devons demander un bearer token à Keycloak, grâce à un client-id ayant la possibilité de faire des demandes de token.
En vous basant sur la procédure précédente, créez un nouveau client nommé ineat-web
Une fois sur l’onglet Settings (après avoir créer le client)
définir l’Access Type en public
activez l’option Standard Flow Enabled
activez l’option Direct Access Grands Enabledqui permet à ce client de pouvoir demander des tokens (nous verrons dans les articles suivants comment utiliser ce client).
Configuration du client ineat-web
Création des roles
Pour finir, nous allons créer deux rôles (associés au domaine) qui seront utilisés par notre backend pour catégoriser un utilisateur lors de son authentification.
Basculez sur l’onglet Roles de l’interface d’administration
Utilisez le bouton Add Role à droite du tableau
Pour les besoins du tutoriel, nous avons besoin de créer
un role ADMIN
un role USER
Création des utilisateurs de tests
Afin de pouvoir tester l’accès à nos futurs URIs (sécurisées), nous allons créer deux utilisateurs possédant chacun un des deux rôles précédemment créé.
Cliquez sur le bouton Add user à droite de l’écran
Création d’un utilisateur ineat-admin
Création de l’utilisateur ineat-admin
NOTE : Activez Email Verified afin de rendre le compte actif par défaut
Après avoir cliqué sur le bouton Save, accédez à l’onglet Credentials
Définissez le mot de passe avec la valeur password (pour les besoins du tutoriel)
Désactivez l’option Temporary pour que notre utilisateur n’ai pas à changer son mot de passe à sa première connexion
Cliquez sur le bouton Reset Password (puis confirmer sur la modale) pour définir le mot de passe
Basculez sur l’onglet Role Mappings afin d’assigner le rôle ADMIN à notre utilisateur
Ajouter ADMIN aux “Assigned Roles“
Répétez l’opération avec un compte ineat-user ayant le rôle USER
Liste des utilisateurs à ce stade de la configuration
That’s it. Notre configuration est prête à être utilisée par nos futurs applicatifs.
One more thing
Pour éviter de ré-itérer l’opération sur différents environnements, Keycloak propose des fonctions d’import / export. Vous pouvez facilement exporter la configuration du domaine que nous venons de créer en accédant à l’onglet Export sur le menu de gauche.
ATTENTION, l’export ne concerne pas les utilisateurs créés
NOTE : Pensez à cocher l’ensemble des options afin d’exporter la configuration complète du domaine :
Astuce : Vous allez pouvoir attacher le fichier realm-export.json aux sources de votre projet afin de pouvoir rapidement (re)monter l’environnement Keycloak.
En guise de compléments
Les informations de votre domaine sont disponibles sous /auth/realms/ineat-realm/.well-known/openid-configuration (lien localhost)
Ou en cliquant sur OpenID Endpoint Configuration de l’onglet General du domaine
La liste des endpoints exposés par Keycloak pour l’authentification des clients est détaillée ici (elle nous servira dans l’article suivant pour tester les accès de nos utilisateurs à l’API)
Dans la prochaine étape, nous verrons comment lier notre configuration Keycloak à un backend Spring afin de sécuriser l’accès à nos URIs d’API REST.
Ce site utilise des cookies Google Analytics à des fins de mesure d’audience. En poursuivant votre navigation, vous acceptez l’utilisation de ces cookies. En savoir plusJ'ai compris
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.