Authentification
L'authentification dans RuleShake est assurée par le standard OpenID Connect basée sur OAuth2.
ruleshake-start permet un démarrage rapide de la suite RuleShake. Il inclut l'installation et la configuration de l'IdP Keycloak.
N'importe quel fournisseur d'identité implémentant ce standard peut être utilisé par RuleShake à la fois pour l'authentification dans RuleShake Studio, mais également lors des appels API des services backend.
Tokens
Les claims suivants du access token et userinfo générés par l'IdP sont attendus par les services RuleShake :
nickname: Obligatoire, nom de l'utilisateur authentifié.name: Optionnel, le nom d'affichage de l'utilisateur (Prénom + Nom par exemple).ruleshake/roles: Obligatoire, la liste des rôles de l'utilisateur.USER: rôle ayant les droits lecture et écriture.GUEST: rôle ayant les droits de lecture uniquement.
ruleshake/organization: Obligatoire, l'identifiant du tenant.
Configuration
Afin de pouvoir générer des tokens, il faut configurer des clients de type OpenID Connect dans le tenant/realm dédié à RuleShake dans l'IdP.
Keycloak sera utilisé pour illustrer la configuration et l'utilisation d'un IdP pour la suite de cette documentation.
Les menus peuvent changer d'un IdP à un autre mais, s'agissant d'un standard, vous retrouverez certainement les mêmes élements.
Realm
Créer dans un premier temps un realm dans Keycloak.
Cliquer sur le bouton Create realm dans le menu déroulant en haut à gauche.
Le nom du realm, préfixé par <url_keycloak>/realms/, sera ensuite défini dans les variables d'environnements :
VITE_AUTH_AUTHORITYpour RuleShake Studio.OAUTH2_ISSUER_URIpour RuleShake Catalog, Runner et Referential.
Rôles
Dans le realm nouvellement créé, accéder au menu Realm roles puis ajouter les rôles USER et GUEST.
Utilisateurs
Dans le menu Users, créer des users en cliquant sur le bouton Add user.
Renseigner ensuite au moins le champ Username valider puis définir un mot de passe dans l'onglet Credentials.
Assigner ensuite le rôle correspondant à l'utilisateur dans l'onglet Role mapping.
Clients
Afin de séparer l'authentification des utilisateurs finaux (qui utilisent RuleShake Studio) des appels "machine-to-machine", nous pouvons créer deux clients. Cependant, il est tout à fait possible d'en créer un seul qui servira pour les deux.
Pour RuleShake Studio
Accéder au menu Clients puis cliquer sur le bouton Create client :
Choisir le type OpenID Connect et renseigner un identifiant et un nom d'affichage pour le client :
Activer ensuite Client authentification et Authorization et cocher les flow Standard flow et Direct access grants.
Renseigner enfin les URLs utilisées par RuleShake Studio.
Valid redirect URIs sont les URLs autorisées après authentification.
Ajouter <url_studio>/auth-callback et <url_studio>/auth-silent-refresh.
Valid post logout redirect URIs sont les URLs autorisées après déconnexion.
Ajouter <url_studio>/login et <url_studio>/logout.
Web origins sont les domaines origines utilisés par RuleShake Studio.
Configuration des claims
Nous allons maintenant définir les claims nécessaires, pour cela accéder à la fiche du client puis cliquer sur l'onglet Client scopes.
Cliquer ensuite sur le ruleshake-studio-dedicated dans lequel nous allons définir les mappers des claims attendus.
Pour ajouter le claim name, nous allons créer un mapper préd éfini.
Cliquer sur le bouton Add mapper puis sur From predefined mappers.
Sélectionner ensuite le mapper full name puis cliquer sur Add.
Pour les autres claims, nous allons créer un mapper en cliquant sur le bouton Add mapper puis choisir By configuration.
Pour ajouter le claim nickname, sélectionner le mapper User attribute.
Saisir nickname dans les champs Name et Token Claim Name.
Saisir username dans le champ User Attribute.
S'assurer que Add to access token et Add to userinfo sont sélectionnés.
Pour ajouter le claim ruleshale/organization, sélectionner le mapper Hardcoded claim.
Saisir ruleshake/organization dans les champs Name et Token Claim Name.
Saisir le nom que vous souhaitez donner à votre tenant dans le champ Claim value.
Choisir le type String dans la liste déroulante Claim JSON Type.
S'assurer que Add to access token et Add to userinfo sont sélectionnés.
Pour ajouter le claim ruleshake/roles, sélectionner le mapper User Realm Role.
Saisir ruleshake/roles dans les champs Name et Token Claim Name.
S'assurer que Add to access token et Add to userinfo sont sélectionnés.
access_token{
"exp": 1707681504,
"iat": 1707681204,
"auth_time": 1707681204,
"jti": "2b63d0b5-f565-418d-a8e9-14bd0353fd59",
"iss": "http://keycloak:9090/realms/ruleshake-samples",
"sub": "26eccfe0-8213-4569-949c-20ef656c1490",
"typ": "Bearer",
"azp": "ruleshake-studio",
"session_state": "9ba6fcb8-d3d2-4063-9299-60e1ff14a6a6",
"acr": "1",
"allowed-origins": [
"http://localhost:8080"
],
"realm_access": {
"roles": [
"USER"
]
},
"scope": "openid profile email",
"sid": "9ba6fcb8-d3d2-4063-9299-60e1ff14a6a6",
"email_verified": false,
"ruleshake/organization": "samples",
"nickname": "user",
"name": "User User",
"ruleshake/roles": [
"USER"
],
"preferred_username": "user",
"given_name": "User",
"family_name": "User"
}
Pour RuleShake Services
Pour créer un client pour les services RuleShake, la démarche est exactement la même que pour RuleShake Studio
à l'exception de ne pas saisir des URLs de redirection, car ce client sera essentiellement utilisé pour récupérer
des tokens avec le grant_type client_credentials pour le compte de service associé au client.
Il est possible d'utiliser le compte de service du client précédent.
S'agissant d'un compte de service, l'assignation du rôle ne peut se faire dans le menu User.
Il faudra se rendre sur la fiche du client puis l'onglet Service account roles.
Cliquer sur le bouton Assign role et choisissez le rôle correspondant.
Pour pouvoir évaluer des collections de RuleShake Runner, il est nécessaire d'avoir le rôle USER