Accueil > OpenID Connect OAuth Server par DnC > Développer > OAuthSD : sujets avancés

Cette rubrique traite de développements exploratoires, au delà des spécifications ou en applications de spécifications non stables.

Applications natives : un exemple avec Windev

  publié le par DnC

Nous donnons ici un exemple d’une application Windows native réalisée avec Windev qui utilise l’authentification OpenID Connect.

Contrairement à une idée trop répandue qui voudrait qu’une application native (donc sans back-end) ne puisse utiliser qu’un flux implicite, cette application met en oeuvre le flux d’autorisation avec code (Authorization Code Grant) d’OpenID Connect en passant par l’interface de bouclage (loopback) du réseau local.

Redirection par l’interface de bouclage du réseau

C’est l’une des trois méthodes décrites dans cet article : OAuth 2.0 (et OpenID Connect) pour les applications natives.

Traduction d’extraits de rfc8252 :

Les applications natives capables d’ouvrir un port sur l’interface de bouclage du réseau peuvent utiliser l’interface de bouclage du réseau pour recevoir la redirection OAuth.

Les URI de redirection de bouclage utilisent le schéma HTTP et sont construits avec l’adresse IP littérale de l’interface de bouclage et le port sur lequel le client écoute. C’est-à-dire http://127.0.0.1:{port‹/{path} pour IPv4 et http: // [:: 1]: {port} / {chemin} pour IPv6.

Exemple avec Windev WD OAuth

Depuis la version 24, Windev permet de réaliser une authentification via le protocole OpenID Connect [1] avec la composante wd240ggl.dll. Voir : Fonction AuthIdentifie.

Cette implémentation répond aux éléments de spécification présentés ci-dessus en employant comme il se doit le flux Authorization Grant (et non un flux implicite), en passant par l’interface de bouclage localhost, ainsi qu’un navigateur extérieur à l’application.

Nous avons modifié l’exemple didactique (WINDEV) WD OAuth pour intégrer une nouvelle classe OAuthSDLogin. Cette classe est absolument identique (au paramétrage près) à la classe GoogleLogin, ce qui prouve la totale compatibilité du serveur OAuthSD.

Ceci permet d’affirmer que toute application assurant l’authentification avec Google OpenID Connect pourra fonctionner avec OAuthSD, pourvu que les paramètres de connexion au serveur d’authentification puissent être modifiés pour adopter ceux d’OAuthSD.

WINDEV

  1. // Classe OAuthSDLogin
  2.         // Gère l'authentification OpenID Connect via OAuthSD. Voir : https://oa.dnc.global/86
  3.         OAuthSDLogin est une Classe
  4.                 hérite de OAuthAppLogin
  5. FIN
  6.  
  7. PROCÉDURE Constructeur()
  8.  
  9. // Appel du constructeur OAuthAppLogin
  10. Constructeur OAuthAppLogin("OAuthSD")
  11.  
  12. // Décrit l'application OAuth
  13. // La clé et le code secret sont inscrits sur le serveur OAuthSD au moment de l'enregistrement de l'application.
  14. m_oServiceOAuth..ClientID = "WindevOAuthSDLogin"                // 'Client ID'
  15. m_oServiceOAuth..ClientSecret = "uhkdfk7bUXWq!"         // 'Client secret'
  16.  
  17.  
  18. dbgVérifieDifférence(m_oServiceOAuth..ClientID, "", "ClientID non renseigné")
  19. dbgVérifieDifférence(m_oServiceOAuth..ClientSecret, "", "ClientSecret non renseigné")
  20.  
  21. // Le flux OAuth 2.0 requiert des 'Scopes'
  22. // "Space-delimited set of scope strings."
  23. m_oServiceOAuth..Scope = "openid profile sli"
  24. // Le flux OAuth 2.0 nécessite deux points d'accès :
  25. // - un point d'accès pour authentifier l'utilisateur
  26. // - un point d'accès pour l'obtention d'un 'AccessToken'
  27. m_oServiceOAuth..URLAuth = "https://oa.dnc.global/authorize"
  28. m_oServiceOAuth..URLToken = "https://oa.dnc.global/token"
  29. m_oServiceOAuth..ParamètresSupplémentaires = "response_type=code"             //
  30.  
  31. // L'URL de callback vers localhost permet à l'application de recevoir le code d'autorisation.
  32. m_oServiceOAuth..URLRedirection = "http://localhost:9000/"
  33.  
  34.  
  35. PROCÉDURE Destructeur()
  36.  
  37.  
  38.  
  39. // Résumé : Lit le profil utilisateur
  40. // Syntaxe :
  41. //[ <Résultat> = ] LectureProfilUtilisateur ()
  42. //
  43. // Paramètres :
  44. //      Aucun
  45. // Valeur de retour :
  46. //      OAuthWebUser : Informations sur l'utilisateur
  47. //
  48. PROCÉDURE VIRTUELLE PROTÉGÉE LectureProfilUtilisateur()
  49.  
  50. clInfo          est un OAuthWebUser
  51. vInfo           est un Variant
  52. oRequête       est une httpRequête
  53. oRéponse       est une httpRéponse
  54.  
  55. oRequête..URL          = "https://oa.dnc.global/userinfo"
  56. oRequête..AuthToken = m_oToken
  57. oRequête..Méthode     = httpGet
  58.  
  59. // Exécute la requête permettant d'obtenir les informations du profil de l'utilisateur connecté
  60. oRéponse <- HTTPEnvoie(oRequête)
  61. SI PAS ErreurDétectée _ET_ PAS oRéponse..CodeEtat >= 400 ALORS
  62.        
  63.         // Décode la réponse JSON contenu dans le message
  64.         vInfo = JSONVersVariant(oRéponse..Contenu)
  65.        
  66.         // Recopie les données lues
  67.         // Attention, les chaînes sont au format ANSI / UTF-8
  68.         // Pour les afficher, il est nécessaire d'utiliser AnsiVersUnicode(<chaîne>, alphabetUTF8)
  69.         clInfo.ID                       = vInfo.id
  70.         clInfo.Nom                      = vInfo.name
  71.         clInfo.NomAffiché      = vInfo.given_name
  72.         clInfo.Image            = vInfo.picture
  73.         clInfo.Email            = vInfo.email
  74. FIN
  75.  
  76. RENVOYER clInfo

Télécharger

Dans le paramétrage de la demande d’autorisation, noter :
- m_oServiceOAuth..Scope = "openid profile sli" : le scope openid entraîne l’utilisation du protocole OpenID Connect.
- m_oServiceOAuth..ParamètresSupplémentaires = "response_type=code" qui entraîne la mise en oeuvre du flux Authorization Code Grant.

Comme d’habitude, le login est "bebert", le mot de passe "012345678"

Après login, l’exemple effectue l’échange des jetons puis une requête userinfo, dont le résultat, guère impressionnant, est cependant probant du bon fonctionnement :

On peut également vérifier le bon fonctionnement de la connexion unique (SLI) avec cette application.

Notes

[1PC Soft nomme "OpenID" ce qui est en fait OpenID Connect.

Identification SSO des utilisateurs identifiés avec Kerberos

  publié le par DnC

L’utilisateur Windows qui a créé une session avec Active Directory (il a déjà fourni son login et son mot de passe) pourra se connecter aux applications Web protégées par OAuthSD sans avoir à entrer dans une nouvelle procédure d’identification.

Kerberos agit comme un Fournisseur d’identité OIDC (OIDC Identity Provider).

La solution décrite s’adresse au serveur Kerberos sans passer pas la passerelle Navigateur->Apache->application (mod_auth_kerb) qui est peu portable et instable.

A propos du logo de Kerberos : dans la mythologie grecque, Cerbère (en grec ancien Κέρϐερος / Kérberos) est le chien à trois têtes gardant l’entrée des Enfers (Wikipedia). Ce logo est adopté par le MIT pour son protocole krb5 qui est utilisé ici.

Objectif

L’utilisateur qui s’est identifié sur le réseau local avec Active Directory est inscrit sur le serveur Kerberos du domaine.

Il s’agit de faire en sorte que cet utilisateur soit également identifié par OIDC, donc sans avoir à suivre une nouvelle procédure de login dans les applications clientes du serveur OAuthSD de l’organisation.

On peut donc dire que le "SSO" d’OauthSD (la connexion unique) héritera de celui de Kerberos.

Solution s’adressant directement au serveur Kerberos

Cette approche est complète car elle permet d’obtenir non seulement le login de l’utilisateur mais également des informations permettant son identification.

De plus, elle ne fait pas appel à la passerelle entre Kerberos et le navigateur, ce qui permet d’éviter des problèmes de configuration des navigateurs des utilisateurs.

Concepts

Le protocole Kerberos définit la façon dont les utilisateurs interagissent avec un service réseau pour avoir accès aux ressources du réseau.

Pour une présentation générale de Kerberos, voyez : Exploration du protocole KERBEROS

Dans Windows, l’ordinateur client est membre d’un domaine AD DS (Active Directory Domain Services) et le ticket TGT prouve que le contrôleur de domaine Kerberos a authentifié les informations d’identification utilisateur.

Si la finalité et le fonctionnement de Kerberos ressemblent à ceux d’OpenID Connect (OIDC), leur niveau fonctionnel (au sens couches ISO du terme) n’est pas le même :

Comparaison fonctionnelle OIDC / Kerberos
OIDC Kerberos
Objectif Authentification des internautes par les applications Web identification des utilisateurs, des machines et des ressources sur le réseau local
Niveau de communication Web Réseau local
Protocole HTTP TCP
Le client est Une application ouverte sur le serveur HTTP, sur l’user-agent ou native capable de protocole HTTP Toute application native fonctionnant sur la machine de l’utilisateur final (ordinateur client) capable d’ouvrir un socket [1]
Le sujet est Une application ou un utilisateur final L’utilisateur ayant ouvert la session Windows

Le tableau suivant met en parallèle les concepts des deux systèmes [2].

Correspondance des Concepts
Auth2 Kerberos
Serveur d’autorisation (AS) Centre de distribution de clés (KDC)
Authentication controller Authentication service (AS)
Authorization Code Ticket to Get Tickets ou Ticket-Granting Ticket (TGT)
Token controller Ticket Granting Service (TGS)
Access token Service ticket

Pourquoi ne pas utiliser mod_auth_kerb ?

Un problème à résoudre consiste à passer les informations kerberos de la couche protocole TCP à la couche protocole HTTP.

Quand on cherche comment le problème est résolu, on trouve généralement des applications de l’extension Apache mod_auth_kerb.

mod_auth_kerb définit la variable d’environnement REMOTE_USER avec l’identification du client, ce que l’on peut récupérer dans l’application. Cela suppose l’intégration des informations Kerberos dans le Header de la requête HTTP.

Les principaux inconvénients sont les suivants :
- Pour fonctionner, cela exige de configurer le navigateur Web pour qu’il utilise réellement l’authentification HTTP Negotiate, dont les détails varient d’un navigateur à l’autre. Certains navigateurs n’implémentent pas cette fonctionnalité.
- La mise à jour ou la reconfiguration du poste de l’utilisateur peut écraser la configuration ou changer le navigateur par défaut.
- Le serveur Apache est nécessaire, Nginx ne semble pas pouvoir être utilisé.

Nous considèrerons donc que la solution n’est ni portable ni stable. Le flux décrit ci-dessous s’adresse directement au serveur Kerberos du domaine.

Il existe des informations complémentaires, connectez vous pour les voir.

Notes

[1Ce qui inclut les applications ouvertes sur le serveur HTTP mentionnées à gauche, pourvu qu’il puisse accéder au serveur Kerberos du domaine.

[2Il ne s’agit pas d’identité puisque le niveau de communication et le sujet de l’authentification ne sont pas les mêmes d’un côté à l’autre. Il faut lire le tableau comme "Dans OIDC xxx joue le rôle du yyy de Kerberos"

[3A partir de ce moment, la session SLI d’OAuthSD et démarrée. Dans l’état actuel du développement, elle vivra indépendamment de la session Active Directory.

[4Dans l’état actuel du développement, OAuthSD ne traite que les identifications Kerberos et Login/Password.

[5A partir de ce moment, la session SLI d’OAuthSD et démarrée. Dans l’état actuel du développement, elle vivra indépendamment de la session Active Directory.

[6Dans l’état actuel du développement, OAuthSD ne traite que les identifications Kerberos et Login/Password.