Connecteur - OpenID Connect (SSO et SLO)
OpenID Connect Protocol
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. See the full documentation of the protocol here : https://openid.net/specs/openid-connect-core-1_0.html
Flot d’authentification : Authorization Code
La plateforme Édifice propose un serveur OAuth2 qui supporte les "flots" suivant :
Authorization Code ,
Resource Owner Passwword
Client Credential
Le flot Authorization Code est un processus sécurisé utilisé pour authentifier un utilisateur et obtenir l'accès à ses informations. Il est particulièrement utilisé pour les applications serveur où la sécurité est primordiale.
Demande d'Autorisation : L'utilisateur commence par tenter de se connecter à une application (le client ou Relying Party). L'application redirige ensuite l'utilisateur vers le serveur d'authentification où l'utilisateur se connecte et donne son consentement pour que l'application accède à ses informations.
Redirection vers le Client : Après la connexion et le consentement, le serveur d'authentification redirige l'utilisateur vers l'application avec un "code d'autorisation" dans l'URL.
Échange de Code contre un Token : L'application envoie ce code d'autorisation au serveur d'authentification, en arrière-plan, souvent en utilisant un secret partagé pour prouver son identité.
Réception du Token d'Accès : En réponse, le serveur d'authentification envoie à l'application un "token d'accès" et parfois un "ID token". Le token d'accès permet à l'application d'accéder à certaines informations de l'utilisateur stockées par le fournisseur d'identité.
Accès aux Ressources : L'application utilise le token d'accès pour demander des informations sur l'utilisateur auprès du fournisseur d'identité.
Déconnexion : Une fois que l'utilisateur se déconnecte, le token d'accès devient invalide.
1 - Authentifier vos utilisateurs via ÉDIFICE
Si vous êtes un éditeur ou un exploitant d’application, demandez au Support Édifice d’enregistrer votre application
Documentation officielle : https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth
Depuis la console d'administration d’une plateforme Édifice créer un connecteur de type OAuth 2.0
Champs à configurer :
Identifiant : [client_Id ]C'est votre identifiant oAuth2 unique pour cette intégration
URL : L'adresse de l'application externe à laquelle vous souhaitez accéder.
openid : Cette option configure automatique est le scope openid pour transmettre les informations de session.
Scope : Autorisations d'accès aux données utilisateurs de l'application externe qui doit être openid.
Mode d'identification : Utiliser "code" pour une application web et "password" pour une application mobile.
client_secret : Paramètre de sécurisation de l’interaction
Informations à transmettre à l'éditeur de l'application cliente :
l'URL du récupération du code temporaire : https://domaine.ent/auth/oauth2/code
l'URL du récupération du token : https://domaine.ent/auth/oauth2/token
l'URL du récupération des information utilisateur : https://domaine.ent/auth/oauth2/userinfo
le clientId (champs "Identifiant")
le secret (champs "Code Secret")
le scope (champs "Scope")
2 - Tester l’accès OIDC de votre application client :
1 : Récupérer code de génération du token
Ouvrez un navigateur et entrez l'adresse adapter pour votre cas Si l'utilisateur n'est pas connecté, la plateforme Édifice redirigera automatiquement le navigateur vers la page de connexion.
Si l'utilisateur est connecté, la plateforme Édifice le redirigera ensuite vers l'URL du service avec le code de réponse inclus dans le paramètre de l'URL
Exemple D’URL :
https://domaine.ent/auth/oauth2/auth?response_type=code&state=blip&scope=openid&client_id=duck&redirect_uri=http://duckduckgo.com
La réponse devrait être comme ceci :
https://www.duckduckgo.com/?code=9ddf3256-7e5d-4708-a121-dfbe5f6dba75&state=blip
L'URL https://www.duckduckgo.com est pris comme client dans notre exemple. Vous devrez l’adapter pour votre url client.
2 - Récupérer le token
Le token d'identification, connu sous le nom d'ID Token, est l'élément central du protocole OpenID et sert à authentifier l'utilisateur. Ce token est obtenu simultanément avec le token d'accès (Access Token) lorsque le scope 'openid' est requis. Outre les champs obligatoires définis dans la section II de la spécification OpenID Connect, le token d'identification inclut également les informations suivantes :
sub
: Identifiant de l’utilisateur.email
: L’adresse courriel de l’utilisateur, si il l’a renseignée.name
: Le nom d’affichage de l’utilisateur.
À l'aide d'un client de requête HTTP tel que cURL, ou d'une application plus complète comme Postman ou un équivalent, vous pouvez suivre les étapes suivantes pour obtenir le token nécessaire à la poursuite du processus d'authentification :
Exemple sur cURL :
curl -i -X POST -H "Authorization:Basic ZmFxMnNjaWVuY2VzOmZhcTJzY2llbmNlcy1zZWNyZXQ=" -H "Content-Type:application/x-www-form-urlencoded" -H "Accept:application/json; charset=UTF-8" -d "grant_type=authorization_code&code=9ddf3256-7e5d-4708-a121-dfbe5f6dba75&redirect_uri=http%3A%2F%2Fduckduckgo.com" https://domaine.ent/auth/oauth2/token
En cas de succès le serveur fournira la réponse dans format suivant :
3 : Récupération des attributs standards selon OpenID Connect
La section V de la spécification OpenID Connect détaille environ une vingtaine d'attributs standards qui peuvent être obtenus via la requête Userinfo notamment :
sub
: Son identifiant.name
: Son nom d’affichage.given_name
: Son prénom.family_name
: Son nom de famille.preferred_username
: Son nom d’affichage.email
: Son adresse courriel.phone_number
: Son numéro de téléphone.
Pour accéder à ces attributs, il est nécessaire d'ajouter le paramètre GET 'version=oidc1.0' à la requête habituelle.
Exemple de commande :
La réponse devrais rediriger l’utilisateur vers votre URL avec les informations de l’utilisateur :
3 - OIDC Back-Channel Logout et SLO ( Single Log Out )
Le Single Log Out (SLO) avec OpenID Connect (OIDC) est un mécanisme permettant à un utilisateur de se déconnecter simultanément de plusieurs applications et services en ligne. Cela est particulièrement utile dans les environnements où un utilisateur accède à plusieurs services ou applications qui utilisent un système d'authentification centralisé.
dans la console d’administration de votre établissement vous devrez ajouter L’URL de déconnexion pour permettre à votre système provider d’identité de vous fournir les informations de déconnexion de l’utilisateur.
1 : Réception du logout token de déconnexion utilisateur.
Après les vérifications, chaque service associé reçoit un token de déconnexion au format JWT via leur URL de déconnexion, précédemment saisie dans le panneau administrateur.
L'objet reçu est un JSON encodé en base 64 et signé avec une clé publique accessible. Il contient des informations concernant l'utilisateur qui effectue la déconnexion.
Voici les informations qu’il contient un fois décodé :