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_AUTHORITY
pour RuleShake Studio.OAUTH2_ISSUER_URI
pour 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