OpenID Connect OAuth Server dédié

La fin des mots de passe : NoPassConnect

DnC — 2021-05-25T14:43:00Z

i-Tego [1] développe NoPassConnect pour le serveur OAuthSD, une application de mobile permettant une identification très sécurisée de l'utilisateur final sans mot de passe.

Fondée sur les meilleures pratiques cryptographiques, cette méthode est fermée à une utilisation publique et se trouve donc particulièrement adaptée à la sécurisation des accès aux données dans un domaine d'entreprise.

OAuthSD + NoPassConnect est une solution idéale pour sécuriser les accès aux applications des entreprises dans le cadre du télétravail.

La vidéo suivante montre comment ouvrir une session OpenID Connect en un clic et sans mot de passe :

Pour fonctionner, NoPassConnect nécessite :
l'application mobile NoPassConnect installée sur un smartphone. Celui-ci doit être connecté à Internet ou connecté au réseau WiFi de l'entreprise ce qui permet une utilisation sanctuarisée dans un espace restreint.
un serveur OAuthSD avec le module d'identification NoPassConnect.
Les applications compatibles OpenID Connect n'ont pas besoin d'être modifiées.

OAuthSD peut intégrer NoPassConnect comme méthode d'identification primaire, qui remplacera avantageusement des systèmes fondés sur des lecteurs de carte par exemple.
NoPassConnect peut également être utilisé comme identification secondaire (Identification à deux facteurs, TFA).

Les avantages de NoPassConnect :

Productivité : NoPassConnect permet une connexion ultra-rapide en mode SSO : il suffit de scanner un QR-Code présenté à l'écran par OAuthSD (une fois au début d'une séance de travail), le reste est automatique.
SmartConnect élimine le besoin de mot de passe et épargne le temps perdu à rétablir les identifiants égarés.

Economie : NoPassConnect est installé sur un mobile ordinaire [2] sans nécessiter de matériel supplémentaire ni de protocoles d'installation complexes. Une entreprise peut envisager d'équiper un très grand nombre d'utilisateurs, y compris extérieurs, pour une fraction du prix d'un système d'identification matériel, avec un gain de temps pour l'administration et la maintenance. C'est l'idéal pour le télétravail !

Faible surface d'attaque : les mots de passe sont le maillon faible de l'identification. NoPassConnect les remplace par des informations cryptographiques robustes, à usage unique.
Les échanges sont limités à une liaison cryptée mobile-serveur OAuthSD.
Il n'y a pas de logiciel à installer sur les stations de travail ou sur les navigateurs (contrairement à un lecteur d'ID card) ; ceux-ci n'interviennent pas dans le protocole d'identification de NoPassConnect, ni a fortiori leurs liaisons publiques, ce qui permet d'éviter deux cibles d'attaques particulièrement vulnérables.

De plus :
NoPassConnect est fondé sur une communication par le réseau de données mobiles (et non l'Internet) entre un mobile connecté et le serveur d'authentification (OP) auquel les applications ont délégué l'identification des utilisateurs.

NoPassConnect ne répond jamais à une demande et ne nécessite pas d'entrée au clavier (pas d'identifiant, de mot de passe ou de code) ce qui ferme la plupart des possibilité d'attaques et distingue la solution de ses concurrentes.

Ces deux caractéristiques sont innovantes et constituent un apport original.

Sécurité : Mieux qu'un mot de passe qui peut être compromis, un smartphone est un objet très personnel, mieux gardé par son propriétaire que tout autre objet. Sa perte ou son vol sont rapidement constatés (alors qu'il n'y a généralement pas moyen de savoir si un mot de passe a été compromis), ce qui permet à un administrateur d'invalider rapidement son enregistrement sur le serveur OAuthSD.

De plus, les smartphones sont équipés de systèmes de reconnaissance biométrique de plus en plus performants. L'identification au moyen du smartphone permet donc de préjuger valablement de l'identité de l'utilisateur final.

Segmentation géographique : Par défaut, l'usage de NoPassConnect peut se faire à partir de n'importe quelle connexion de données, qu'il s'agisse du réseau d'un opérateur ou d'un réseau WiFi. L'usage de NoPassConnect peut-être limité au réseau WiFi de l'entreprise, jusqu'à sélectionner par leur IP locale les bornes autorisées. Il serait également possible d'autoriser une connexion domestique donnée pour permettre le travail à domicile. Il est également possible, sur un réseau d'entreprise, de définir les postes de travail capables ou non de se connecter avec NoPassConnect .

Authentification : NoPassConnect impose l'identifiant OpenID de l'utilisateur, qui est intégré au moment de la configuration initiale du mobile sous le contrôle d'un administrateur. Au cours de cette opération, le mobile doit scanner un QR-Code présenté par l'administrateur, ce qui permet d'identifier l'utilisateur avec rigueur ( à l'opposé de l'enregistrement à distance tel que pratiqué par WebAuthn par exemple ).

Les administrateurs peuvent affecter en temps réel les autorisations ou dénier les accès. Plusieurs dispositifs permettent de détecter et de bloquer automatiquement des usages détournés, comme par exemple l'utilisation d'une autre station de travail que celles qui auront été autorisées, etc.

En résumé, les avantages déterminants pour la sécurité des données d'une entreprise sont : l'utilisation de moyens privés, l'identification de l'utilisateur assurée par un administrateur, la possibilité de limiter l'usage à des lieux déterminés.

Entendu ...

Bah, trop simple le QR-Code qui sert de mot de passe !

Pas du tout : le QR-Code n'est qu'un identifiant de session pour les échanges qui vont suivre entre le serveur et le smartphone. Il est éphémère et ne peut donc être réutilisé. L'authentification résulte d'un échange de données faisant appel à des techniques cryptographiques fortes. Le navigateur n'intervient pas dans les échanges qui se font directement entre le smartphone et le serveur OAuthSD.

Ah oui, c'est un Time-based One-time Password (TOTP) comme Google Authenticator !
Eh bien non :

NoPassConnect est un dispositif privé, ne faisant pas appel à des systèmes tiers, pour une meilleure sécurité et une parfaite confidentialité.

NoPassConnect impose l'identité de l'utilisateur de l'entreprise, configurée par un administrateur. Un TOTP ne fait que vérifier que l'utilisateur est bien celui qui s'est inscrit lui-même sur le système. En somme, un TOTP protège l'utilisateur tandis que NoPassConnect protège l'entreprise propriétaire du serveur OAuthSD.

OAuthSD propose le TOTP Google Authenticator pour l'authentification à deux facteurs : jugez de la différence par vous même.

Ah oui, c'est comme la confirmation par SMS !
Eh bien non :

Le 2FA par SMS n'est pas sécurisé, alors que NoPassConnect échange des données cryptées sur un canal sécurisé avec SSL/TLS.

De plus le code reçu par SMS doit être retourné par le même canal (le navigateur), ce qui ouvre la porte à de nombreuses techniques d'interception telles que le l'ingénierie sociale, l'interception de trafic, le key-login ; avec NoPassConnect le navigateur n'intervient pas dans ces échanges, l'identification se fait entre le smartphone et le serveur OAuthSD.

Et si c'est l'utilisateur final lui-même qui a fourni son numéro de portable au moment de son inscription, on n'a absolument aucune information sur son identité réelle ! NoPassConnect impose la configuration du smartphone sous le contrôle d'un administrateur.

J'ai trouvé : c'est comme WebAuthn !

C'est assez proche en apparence, mais très différent : NoPassConnect concoure à l'ouverture et à la fermeture d'une session OpenID Connect à partir d'une application qui lui est extérieure, tandis que WebAuthn se limite à l'identification directe de son porteur.

C'est également très différent en termes de sécurité :

WebAuthn présente un désavantage important pour la sécurité d'une entreprise : comme la plupart des système de login, WebAuthn est un système public dans le sens où c'est l'utilisateur qui enregistre de façon anonyme son mobile, rien ne permet de l'identifier. Permettre à un utilisateur de s'enregistrer sans qu'il y ait une étape d'identification physique, c'est exactement comme lui permettre de fabriquer lui-même sa carte d'identité, et encore : en remplaçant son nom par un pseudo.

A l'inverse, l'enregistrement d'un mobile NoPassConnect est fait à l'initiative et sous le contrôle d'un administrateur de l'entreprise, en présentiel, ce qui permet d'enregistrer dans le serveur OpenID Connect l'identité réelle de l'utilisateur.

Enfin, répétons-le : avec NoPassConnect, le navigateur n'intervient pas dans le processus d'identification qui se fait directement entre le smartphone et le serveur OAuthSD.

Ah oui, c'est un peu comme un lecteur d'ID card ...
Presque ! En mieux :

C'est plus économique, plus facile à déployer, moins vulnérable.

De plus, NoPassConnect n'étant pas lié physiquement à un poste de travail, il peut être déployé hors du périmètre de l'entreprise. Cela n'interdit pas de limiter l'utilisation de NoPassConnect à un ou plusieurs postes de travail, c'est l'un des avantages de scanner le QR-Code affiché par le poste de travail !

Enfin, si un utilisateur peut oublier sa carte dans le lecteur en quittant le bureau, il est probable qu'il n'oubliera pas de prendre son smartphone avec lui...

[1] i-Tego est une nouvelle société créée en juillet 2021 après la fermeture de DnC en décembre 2020. B.D. a commencé le développement de SmartConnect dans l'intervalle en utilisant provisoirement ce site web en attendant qu'i-Tego possède son propre site documentaire

[2] Actuellement sur système Android, IOS en cours de développement.

[DR] Composants logiciels de OAuthSD / SmartConnect

SmartConnect est une application de mobile (4) ( Android ou iOS) qui nécessite un serveur OAuthSD (1). Pour son fonctionnement, l'application SmartConnect est en relation avec un module d'authentification (2) (Pluggable Authentication Module, PAM) intégré à OAuthSD, mais n'est pas connecté aux applications compatibles OpenID Connect (3).
SmartConnect se situe au sein des distributions OAuthSD comme représenté dans le le tableau suivant :

Dans ce tableau, les composants sur fond bleu-clair sont développés par DnC :

OAuthSD comprend trois groupes de composants :
le Superviseur, est une application Web permettant aux administrateurs d'enregistrer les applications clientes d'OAuthSD, de contrôler l'inscription des utilisateurs et de leurs droits sur les applications et enfin de suivre le fonctionnement des authentifications.
Le Daemon (le serveur OIDC à proprement parler) qui est construit sur des modules intermédiaires (middleware) développés par DnC fournissant la version haut-niveau des contrôleurs Authorize, Token etc., et finalement sur des bibliothèques open-source pour le code de bas-niveau.
Des modules d'authentification (Pluggable Authentification Modules (PAM)) intégrés à OAuthSD assurant l'identification primaire et secondaire pour l'identification à deux facteurs.

Le module NoPassConnect (ex IdentMaster, SmartConnect) assure la communication entre le mobile équipé de l'application NoPassConnectet le serveur. Il comporte également une application qui permet aux administrateurs de configurer l'instance NoPassConnectd'un mobile donné et de l'enregistrer sur le serveur.

Pour pouvoir déléguer l'authentification au serveur OAuthSD, les applications doivent être dotés d'un module OpenID Connect. De plus en plus d'applications professionnelles intègrent un tel module. Les applications qui ne sont pas directement compatibles offrent souvent un système de modules qui permet d'ajouter la fonctionnalité OIDC. Il en est ainsi de WordPress et de phpBB.

Les applications d'Identité sont des logiciels dédiés installés sur le mobile au-dessus du système d'exploitation Android, iOS, BlackBerry, etc. Ce sont donc des applications natives, à l'inverse par exemple de l'authentification par SMS qui s'appuie sur une application existante ou d'autres procédés s'appuyant sur le navigateur. L'application NoPassConnect est une application native, développée en Java, qui peut être installée par l'utilisateur.

[CONF] Particularités du procédé en faveur de la sécurité

[CONF] Comparé au principe du TOTP ou de la vérification par SMS (un code dépendant de l'utilisateur et limité dans le temps), SmartConnect est beaucoup plus sécurisé : le QR-Code est à usage unique, et la réponse de l'application SmartConnect intègre l'identifiant OpenID de l'utilisateur et l'ID du mobile, mixé avec un alea qui rend la réponse unique, le tout transmis au moyen d'un jeton crypté.

[CONF] Notons également que, contrairement à un système de confirmation TFA, l'utilisateur n'est pas interrogé à l'initiative d'un système dont il ignore le lien réel avec l'application légitime (celle qu'il veut lancer), mais c'est lui qui prend l'initiative de poursuivre (en scannant le QR-Code) le dialogue d'authentification qu'il a initialisé depuis l'application. L'utilisateur est actif au lieu d'être passif. Le mobile ne traite pas de connexion entrante, mais utilise le canal de retour de la connexion qu'il a lui-même établie, le mettant ainsi à l'abri d'attaques web.

[CONF] Enfin, le terminal sur lequel s'affiche le QR-Code se trouve lié dans le processus d'authentification, ce qui permet au serveur OAuthSD de s'assurer que l'utilisateur est bien devant le terminal. Ainsi, les authentifications ne peuvent être initiées que depuis des terminaux répertoriés.

Expérimental : téléchargez et installez l'application sur votre mobile Android

Sur votre mobile Android :

Téléchargez l'APK :
i-tego.com/store/app-release.apk
Activez les sources inconnues :
Allez dans les paramètres, puis Sécurité
Recherchez l'APK sur votre téléphone (à l'aide d'un explorateur de fichiers par exemple)
Lancez le fichier APK et suivez les instructions
Désactivez les sources inconnues

Identification OpenID Connect avec ID Card : Aramis

DnC — 2020-11-10T07:03:00Z

Les grandes organisations possèdent généralement leur propre système d'identification attaché à chaque poste de travail, le plus commun étant le lecteur d'ID card.

OAuthSD a permis par exemple d'intégrer le système de lecteur de carte Aramis. Ainsi, un utilisateur identifié par ce moyen l'est également par les applications Web clientes du serveur OAuthSD, auxquelles le jeton d'identité JWT transmettra le profil Aramis de l'utilisateur.

S'il fallait résumer les avantages de la solution OAuthSD + ARAMIS, le mieux serait :

La conjonction d'OAuthSD et d'ARAMIS permet d'assurer l'authentification des utilisateurs par les applications extérieures, sans procédure de login/mot de passe, tout en sanctuarisant les données sensibles des utilisateur sur le réseau interne de l'entité, sans rien changer à ces données, les comptes et les droits restant gérés exclusivement par ARAMIS.

Les avantages vont donc bien au-delà d'un simple système de connexion unique (Single Sign On, SSO).

La gestion des utilisateurs est effectuée exclusivement par Aramis

Dans cette configuration, c'est le système Aramis qui gère les données relatives aux utilisateurs et fournit l'User ID : Le serveur OAuthSD fonctionne avec la table 'users' vide !

L'identifiant de l'utilisateur final est fourni par le système Aramis. C'est cet identifiant qui figurera dans la déclaration 'sub' du jeton d'identité JWT.

OAuthSD permet donc d'intégrer un système d'identification existant sans nécessité d'une double maintenance ou d'une synchronisation des tables des utilisateurs.

Incorporation des données Aramis dans le jeton d'identité JWT

OAuthSD permet d'incorporer dans le jeton d'identité des données supplémentaires issues d'Aramis. Le mécanisme général est décrit ici : Incorporer au jeton JWT des déclarations supplémentaires.

Un système d'identification xxx propre à une application OAuthSD dédiée est intégré au moyen d'un script /oidc/identification/xxx/login.php particulier. Ce script place les données de l'utilisateur issues du système dans une variable de session $_SESSION['user_claims'], sous forme cryptée.

Les données seront automatiquement incorporées au jeton d'identité JWT sous la forme d'une déclaration supplémentaire pour chaque membre de premier niveau de l'array 'user_claims'.

Il est ainsi possible de passer de façon sûre des données de profil de l'utilisateur final authentifié qui permettront aux applications destinataires du jeton JWT de gérer l'accès en fonction des droits de l'utilisateur qui auront été définis au niveau d'Aramis.

Userinfo

La table users étant vide, le contrôleur UserInfo ne peut retourner les données de l'utilisateur sans modification du code. Si nécessaire, un nouveau contrôleur UserInfo devra être créé pour retourner les données extraites de la carte Aramis. Notons cependant que la fonctionnalité Userinfo ne faisant pas partie du "standard" OpenID Connect, le serveur OAuthSD est donc conforme en l'état.

Le développement réalisé pour la CRAMIF

L'objectif de la CRAM Ile-de-France (CRAMIF) était de sécuriser la connexion des utilisateurs de son application de signature électronique, le SAAS Web "Lex Persona", à partir des postes de travail internes aussi bien que depuis le Web. Pour cela, nous avons installé notre serveur OpenID Connect "OAuthSD" sur l'infrastructure informatique de la CRAM Ile-de-France (CRAMIF).

Le système d'identification par carte "Aramis" a été intégré au serveur OAuthSD : les utilisateurs sont gérés par le système existant, et les autorisations pré-établies des différents acteurs sont automatiquement intégrées au jeton d'identité et transmises à Lex Persona au moyen de celui-ci.
Notons que cette technique dispense totalement l'utilisateur de tout dialogue de connexion, ce qui procure un confort et un gain de temps appréciables.

P.V. Responsable du Départements ETUDES INFORMATIQUES : "Vous avez développé un produit fantastique qui simplifie la vie de nombreux utilisateurs et qui, malgré tous vos efforts, reste méconnu. Je sais que nous pourrons compter sur vous en cas de besoin et je vous en remercie."

OAuthSD peut intégrer tout pourvoyeur d'identité

La structure modulaire d'OAuthSD permet d'intégrer tout pourvoyeur d'identité, Aramis n'étant qu'un exemple.

Il est également possible d'intégrer plusieurs systèmes simultanément.

En particulier, remarquant qu'une identification par carte identifie la carte, pas le porteur, il est opportun de demander une deuxième authentification (TFA), cette dernière requérant un élément dans la possession de l'utilisateur à authentifier.

Validation en 2 étapes (Two Factor Authentication, 2FA)

DnC — 2020-06-19T09:10:00Z

Un règlement de l'UE ( en vigueur depuis septembre 2019 ) exige une authentification de paiement à deux facteurs, appelée « Authentification client forte » (SCA).

Le besoin de la validation à 2 étapes se fait également sentir pour la connexion des utilisateurs aux applications sensibles. Le principe de la validation à 2 étapes (Two Factor Authentication, 2FA) est bien connu depuis plusieurs années et mis en oeuvre de différentes manières, la plus courante étant le code envoyé par SMS.

OAuthSD implémente l'authentification à deux facteurs par SMS ou avec Google Authenticator.

Qu'est-ce que 2FA ?

La sécurité apportée par un simple mot de passe n'est pas toujours suffisante.

L'authentification à deux facteurs, également connue sous le nom de 2FA, vérification en deux étapes ou TFA, est une couche de sécurité supplémentaire appelée « authentification à plusieurs facteurs », qui requiert non seulement un mot de passe et un nom d'utilisateur, mais aussi quelque chose que cet utilisateur possède, qui est avec lui et que personne d'autre ne possède ou ne connait.

Après le login, donnez une deuxième preuve de votre identité

Le processus commence comme d'habitude, l'utilisateur final donnant son identifiant et son mot de passe :

Il lui est demandé de fournir une deuxième preuve d'identité : OAuthSD propose la méthode classique par SMS ou l'identification avec Google Authenticator.

2FA par SMS

Si cette première étape se termine avec succès, OAuthSD enchaîne sur une demande de code par SMS :

Le SMS est envoyé au numéro de smartphone enregistré avec le profil de l'utilisateur [1].

Après confirmation, le consentement est demandé si nécessaire, comme d'habitude :

2FA avec Google Authenticator

Google Authenticator est un système de 2FA qui génère un TOTP.

Qu'est-ce que TOTP ?

TOTP est une forme abrégée de "Time-based One-time Password " ou "mot de passe à utilisation unique à durée déterminée". Il s'agit d'un mot de passe qui ne peut être utilisé qu'une seule fois et qui ne peut être utilisé que dans une plage de temps définie. Généralement, les générateurs TOTP génèrent de nouveaux mots de passe toutes les quelques dizaines de secondes tel que défini.

Après le login, donnez une deuxième preuve de votre identité avec Google Authenticator

Le processus commence comme d'habitude, l'utilisateur final donnant son identifiant et son mot de passe comme précédemment.

Il lui est demandé de fournir une deuxième preuve d'identité : Google Authenticator qu'il ou elle a installé sur son smartphone lui donnera le code nécessaire.

Cela nécessite d'enregistrer OAuthSD sur Google Authenticator en tant qu'application [2]. C'est pour cela que le QRCode est utilisé. Voir de nombreux tutoriels sur le Web. C'est une action unique pour la vie du smartphone : une fois que c'est fait, GA affichera un code toutes les 30 secondes : rien à retenir !

Après confirmation, le consentement est demandé si nécessaire, comme d'habitude.

Pourquoi Google Authenticator ?

Qu'en est-il du suivi (tracking) ? Les applications délèguent l'identification de l'utilisateur à OAuthSD. Cela signifie que Google voit le serveur OAuthSD et non les applications. Google sait qu'un utilisateur est lié à OAuthSD, mais ne voit pas la relation avec l'application : il n'y a donc pas de suivi de l'activité de l'internaute sur l'application (tracking) ... à condition qu'il n'y ait pas de fuite de suivi ailleurs dans cette application !

TFA avec NoPassConnect

Nous développons NoPassConnect (précédemment SmartConnect), une application de mobile sans mot de passe (passwordless) qui peut être utilisée comme première méthode d'authentification aussi bien qu'en deuxième.

Avec l'application NoPassConnect installée sur votre mobile, il vous suffit de scanner le QR-Code présenté par l'application pour ouvrir votre session OpenID Connect :

Configurer TFA sur OAuthSD

Une demande de deuxième validation est présentée à l'utilisateur final :
Si la constante de configuration LOGIN_WITH_TFA est définie sur true, le formulaire 2FA sera toujours présenté à l'utilisateur final après le formulaire de connexion.
sinon, le scope réservé "tfa" doit être présent dans la demande d'autorisation ; l'application devra donc avoir été enregistrée sur le serveur avec le scope 'tfa'.
la constante de configuration TFA_PROVIDER permet de définir le deuxième mode d'identification ('gangsta', 'checkbysms', 'smartconnect' ...).

Et ensuite ?

Dans l'état actuel du développement, il existe trois méthodes disponibles pour 2FA : TFA par SMS (la solution classique !), Google Authenticator et DnC NoPassConnect.

D'autres fournisseurs d'identités suivront bientôt, y compris le nôtre (= votre serveur privé) pour une sécurité de niveau supérieur.

Nous pouvons développer tout système privé adapté aux besoins particuliers de nos clients, comme nous l'avons fait avec l"'Identification OpenID Connect avec ID Card : Aramis .

[1] La méthode d'identification par SMS échouera donc si aucun numéro n'a été enregistré pour l'utilisateur qui tente de s'identifier.

[2] Notons que c'est bien OAuthSD qui est enregistré sur Google Authenticator, et non les applications clientes. On conserve donc tout l'avantage de la délégation d'authentification pour interdire le tracking de la navigation des utilisateurs finaux.

Utiliser SPIP comme pourvoyeur d'identité d'OIDC

DnC — 2020-05-01T07:42:36Z

De nombreuses applications avancées peuvent être construites en intégrant un serveur OIDC dans un gestionnaire de contenu (Content Management System, CMS) ou un framework. Soit que le CMS serve d'hôte pour développer l'environnement de gestion du serveur OIDC, soit que l'authentification serve, par exemple, à construire un système de distribution d'applications en tant que service (Software as Service, SaaS).
Chez DnC, nous utilisons le CMS SPIP [1] pour ces deux approches, et d'autres applications encore [2].
Cependant, il existe une difficulté : le CMS possède déjà son propre système d'identification des utilisateurs (les 'auteurs'), comment éviter de doublonner avec les utilisateurs finaux enregistrés sur le serveur OIDC ?

Synchroniser les tables 'auteurs' et 'users' ou se passer de la table 'users' ?

En l'état nous avons deux tables : 'users' pour OIDC et 'auteurs' pour SPIP. Le problème à résoudre est donc d'unifier les données.
Deux solutions sont possibles :
la mauvaise : assurer la synchronisation de la table 'users' à partir de données de la table 'auteurs' de SPIP : tout enregistrement de données sur la table 'auteurs' est répercuté sur la table 'users', et vice-et-versa.
la bonne : utiliser uniquement les données de SPIP.

Utiliser SPIP comme pourvoyeur d'identité

Dans cette deuxième solution, les données de SPIP sont utilisées pour réaliser la fonction d'identification du serveur OIDC. Cela nécessite donc un nouveau module d'identification 'spip' comprenant des scripts login.php et login_return.php qui utiliseront les données de la table auteurs de SPIP.

Et le serpent se mord la queue...

Une fois le serveur OAuthSD intégré à SPIP comme indiqué, il peut non seulement être utilisé pour l'authentification des utilisateurs d'applications tierces ou l'accès aux ressources protégées (ce pour quoi est fait un serveur OIDC), mais également pour authentifier les utilisateurs (auteurs) de SPIP en se substituant au module d'authentification standard de ce CMS.

[1] SPIP est dans le Socle interministériel de logiciels libres.

[2] Cet article est le premier d'une série à venir qui développera l'intégration d'un serveur OIDC dans SPIP et les usages qui peuvent en être faits.

acr_values (Requested Authentication Context Class Reference)

DnC — 2020-01-05T11:25:29Z

OAuthSD met en oeuvre acr_values et résoud un problème de sécurité lié à la définition de la méthode d'identification éventuellement imposée par un client.

Traduction d'extraits de OpenID Connect Core 1.0.
Dans la section '2. ID Token' :

acr
OPTIONNEL. Référence de classe de contexte d'authentification. Chaîne spécifiant une valeur de référence de classe de contexte d'authentification qui identifie la classe de contexte d'authentification satisfaite par l'authentification. La valeur "0" indique que l'authentification de l'utilisateur final ne répond pas aux exigences du niveau 1. ISO / IEC 29115 [ISO29115]. L'authentification à l'aide d'un cookie de navigateur de longue durée, par exemple, est un exemple où l'utilisation du "niveau 0" est approprié. Les authentifications de niveau 0 NE DEVRAIENT PAS être utilisées pour autoriser l'accès à toute ressource de quelque valeur monétaire que ce soit. (Cela correspond au PAPIER OpenID 2.0 [OpenID.PAPE] nist_auth_level 0.) Un URI absolu ou un nom enregistré RFC 6711 [RFC6711] DEVRAIT être utilisé comme valeur acr ; les noms enregistrés NE DOIVENT PAS être utilisés avec une signification différente de celle qui est enregistrée. Les parties utilisant cette allégation devront s'entendre sur la signification des valeurs utilisées, qui peuvent être spécifiques au contexte. La valeur acr est une chaîne sensible à la casse.

dans la section '3.1.2.1. Authentication Request' :

acr_values
OPTIONNEL. Valeur de "Requested Authentication Context Class Reference". Chaîne séparée par des espaces spécifiant les valeurs acr que le serveur d'autorisations est invité à utiliser pour traiter cette demande d'authentification, les valeurs apparaissant par ordre de préférence. La classe de contexte d'authentification satisfaite par l'authentification effectuée est renvoyée sous la valeur de revendication acr, comme spécifié à la section 2. La revendication acr est demandée en tant que revendication volontaire par ce paramètre.

Niveaux d'acr

OAuthSD définit quatre niveaux d'acr (au moins, le nombre n'est pas limité) attachés aux méthodes d'authentification et définis par un nombre entier, par ordre croissant de sécurité du procédé :
0 : procédé insuffisant
1 : procédé normal : "une étoile" : login/MdP, délégation de l'identification sans TFA.
2 : procédé "deux étoiles",
3 : procédé "trois étoiles".

En cas d'authentification à deux facteurs (TFA) réussie, les niveaux des deux méthodes sont ajoutés, sinon le niveau est 0 si le TFA échoue.

Les méthodes d'authentification et leur acr sont définis dans le fichier de configuration configure_oidc.php.

Le niveau d'acr est inscrit dans le cookie SLI et est retourné dans la charge utile du jeton JWT.

Méthode d'authentification imposée par le client

OAuthSD permet à un client de spécifier des exigences particulières en matière d'identification de l'utilisateur final afin d'atteindre un niveau acr (Authentication Context Class Reference) suffisant.

Cela est défini par deux champs OPTIONNELS de la table des clients, renseignés au moment de l'inscription de l'application sur le serveur OAuthSD :

identity_provider : nom d'une méthode d'identification principale spécifique (password, ghostkeys, kerberos, etc.).
S'il n'est pas défini, le fournisseur d'identité est celui qui est défini par défaut au moyen de la constante de configuration IDENTITY_PROVIDER.

required_acr : valeur d'acr minimale requise par le client (Requested Authentication Context Class Reference). Si le client ne définit pas de valeur d'acr minimale, celle-ci est définie à 0.

Problématique de sécurité et solution

Il se pose alors un problème de sécurité : si une session OIDC est créée avec une méthode faible, le cookie SLI ou le jeton d'identité JWT permettraient d'accéder à une application requérant une méthode plus forte.
Afin de prévenir cela :
Lorsqu'une authentification est effectuée, la valeur de l'acr est inscrite dans le cookie SLI et le jeton d'identité.
Lorsque authorize vérifie le cookie SLI ou le JWT, si l'acr demandé par l'application est supérieur à l'acr du cookie SLI ou du JWT, on invalidera le cookie, ce qui provoquera une nouvelle authentifiction.
Une application ne déclare pas nécessairement l'acr requis, le niveau étant alors 0.

Systèmes d'identification intégrés à OAuthSD

DnC — 2019-05-16T12:09:00Z

Il s'agit d'identifier une personne, pourquoi alors choisir un masque comme logo de cet article ? C'est parce que la plupart des techniques n'identifient pas une personne avec certitude, sauf quand on utilise des procédés biométriques : de la même manière que l'on peut reconnaître une personne masquée par ses yeux. C'est aussi parce que l'enjeu est de démasquer les intrus.

Les systèmes d'identification intégrés au serveur offrent une sécurité maximale puisqu'ils sont sanctuarisés dans l'espace physique de l'organisation.

Les fenêtres de dialogue nécessaires à l'identification sont produites par le serveur et exécutées dans son environnement : le navigateur de l'utilisateur final a été redirigé vers le domaine du serveur.

OAuthSD offre différentes méthodes d'identification est peut facilement en intégrer de nouvelles grâce à son organisation modulaire.

Identification classique : login/Mot de passe

La méthode se passe de commentaire. Si ce n'est pour dire qu'il faut absolument l'éviter, ainsi que toutes ses semblables exigeant l'entrée au clavier d'un code quelconque, fut-il éphémère !

Goshtkeys : clavier fantôme

Cette méthode affiche une grille dans laquelle l'utilisateur devra cliquer sur des chiffres disposés de façon aléatoire à chaque affichage du formulaire de connexion.
Cette méthode offre de grands avantages de sécurité :
le mot de passe est matérialisé sous une forme codée et variable, ce qui interdit sa réutilisation en cas d'interception,
les robots seront éliminés, ce formulaire étant équivalent à un Captcha.

Après l'identification

Après identification, il est possible d'effectuer une Validation en 2 étapes (Two Factor Authentication, 2FA) .

Enfin, le consentement de l'utilisateur pour l'accès de l'application à ses données personnelles est demandé comme nécessaire :

[DR] Implémentation des méthodes d'identification dans le serveur OAuthSD

OAuthSD distingue les fournisseurs d'identité primaire et, si l'identification à deux facteurs (2FA) est activée, les secondaires. Les constantes de configuration IDENTITY_PROVIDER et TFA_PROVIDER permettent de définir quel seront les systèmes utilisés.

Constantes de configuration
Le fichier /commons/configure_oidc.php permet de configurer les méthodes d'identification :

/** [dnc10]
Que faire si prompt n'est pas défini (ou Null) et que l'utilisateur n'est pas connecté?
*/
define ('REAUTHENTICATE_NO_ROUNDTRIP', true); // True pour que le serveur gère la réauthentification. false est conforme à la norme.
/** Fournisseur d'identité primaire (formulaire de connexion ...).
* Le fournisseur d'identité est la première étape si TFA est activé.
* OAuthSD offre nativement 'ghostkeys', 'password' ...
* [dnc91] Peut être remplacé par le champ identity_provider de la table des clients.
*/
define ('IDENTITY_PROVIDER', 'password');
/** Options de connexion / mot de passe */
define ('PSWD_LENGTH', 9); // longueur exacte du mot de passe
define ('LOGIN_MIN_LENGTH', 5); // login min longueur
define ('FORCE_EMAIL', FALSE); // Si TRUE, la connexion devrait être une adresse électronique. Si FALSE, la connexion peut être un pseudo ou un email.
/** [dnc10] Que faire si une invite == login et que l'utilisateur n'est pas connecté (le jeton d'accès a expiré)?
* Spec a dit que nous devrions retourner au client avec une erreur.
* Il est plus sûr et meilleur (pas d'aller-retour) de gérer la situation sur le serveur.
*/
define ('LOGIN_NO_ROUNDTRIP', true); // True pour que le serveur gère la réauthentification. false est conforme à la norme.
/** En cas de répétition de la connexion au serveur, combien d'essais sont autorisés pour l'utilisateur final? */
define ('ALLOWED_ATTEMPTS', 5);
/** [dnc43] Authentification à deux facteurs (fournisseur d'identité secondaire).
* Un TFA peut être présenté à l'utilisateur final si le champ d'application "tfa" est présent dans la demande d'autorisation.
* Si ce paramètre est défini sur true, le fichier TFA sera toujours présenté à l'utilisateur final après le formulaire de connexion.
*/
define ('LOGIN_WITH_TFA', false);
/** [dnc43] Fournisseur d'identité secondaire. Désigner quel fournisseur sera utilisé pour le TFA.
* Entrez le nom du répertoire dans / oidc / identification / où se trouve le TFA souhaité.
*/
define ('TFA_PROVIDER', 'checkbysms'); // Un parmi 'gangsta', 'checkbysms', ... (rien d'autre pour l'instant).
/** Nom du serveur à passer à getQRCodeGoogleUrl.
* Sera affiché sous le QR-Code.
*/
define ('TFA_VISIBLE_APPNAME', 'Serveur OAuthSD');
/** [dnc9] Si SLI échoue, devons-nous revenir au client?*/
define ('LOGIN_AFTER_SLI_FAILS', true); // le contrôleur authorize est responsable de l'invite à nouveau.

Télécharger

Méthode imposée par l'application
...

Délégation de l'identification, déclaration privées

...

Identification par OpenID Connect des utilisateurs identifiés avec Kerberos

DnC — 2018-12-15T06:56:00Z

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 alors vis-à-vis du serveur OIDC 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,
d'améliorer la sécurité en restant dans une liaison serveur-serveur (le navigateur ne voit pas passer d'information d'authentification).

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 fournies par l'utilisateur de l'ordinateur client.

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] [2].
Le sujet est	L'utilisateur final (ou l'application si elle demande l'authentification pour elle-même)	L'utilisateur ayant ouvert la session Windows

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

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
URL de la ressource	Service Principal Name (ou simplement Principal), SPN

Note à propos de la sécurité

Notons que OIDC opère au niveau applicatif (et non au niveau du réseau), ce qui contribue à l'approche "accès zéro-confiance au réseau" (ZTNA).
Donc il ne faudrait pas utiliser Kerberos ? Ici, nous utilisons Kerberos pour l'identification et l'autorisation de l'utilisateur. L'accès à l'application (ou de l'application aux ressources protégées) reste contrôlé au niveau applicatif.

Pourquoi ne pas utiliser mod_auth_kerb ?

Pour réaliser l'intégration de Kerberos comme pourvoyeur d'identité au profit d'OpenID Connect, un premier problème à résoudre consiste à passer les informations Kerberos de la couche de transport 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 travail 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, qui s'adresse directement au serveur Kerberos du domaine, évite les difficultés et présente une meilleurs sécurité en évitant de passer par le navigateur .

Voici l'implémentation d'OAuthSD :

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

[2] Donc n'importe quelle application, y compris un malware : on ne sait pas où vont les données !

[3] Il 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"

Flux de l'Authentification OIDC avec Kerberos

(Nota : développement en cours)

Le serveur OIDC tente d'utiliser une éventuelle authentification Kerberos avant toute autre méthode d'identification de l'utilisateur. Le flux est le suivant :

l'application cliente demande un code d'autorisation au serveur OAuthSD (contrôleur Authorize) en passant le scope 'kerberos',
En se fondant sur l'adresse de sous-réseau, OAuthSD teste si l'ordinateur client est dans le domaine ou le sous-domaine autorisé du réseau local (précisé dans la configuration du serveur OAuthSD),
OAuthSD interroge le DNS du domaine avec l'adresse de sous-réseau et obtient l'id de la machine sous la forme monserveur.monreseau.local et forme l'adresse kerberos HTTP/monserveur.monreseau.local@MONRESEAU.LOCAL.
OAuthSD se connecte à Kerberos en créant un principal kerberos avec les identifiants de l'administrateur,
OAuthSD examine si la machine a un ticket de session valide, et en extrait l'identité de l'utilisateur,
OAuthSD détruit sa connexion Kerberos.
si la machine est authentifié par Kerberos, le serveur OAuthSD vérifie que l'utilisateur figure bien dans la table users.
le serveur OAuthSD crée ou met à jour le cookie SLI [1].

Si l'authentification Kerberos n'est pas autorisée ou échoue, le serveur OAuthSD passe à la méthode d'identification suivante [2].

Dispositions de sécurité

Inscription de l'utilisateur AD sur OAuthSD
Pour améliorer la sécurité, on peut exiger que le contrôleur Authorize vérifie que l'utilisateur AD est également enregistré sur le serveur OAuthSD .
Dans ce cas, l'utilisateur final devra être inscrit indépendamment sur le serveur OAuthSD, avec le même identifiant que sur AD.
Cette disposition est une option contrôlée par la constante de configuration KERB_USER_EQUALS_OIDC_USER définie à True par défaut.

Le scope 'kerberos'
Ce scope doit figurer dans la liste des scopes disponibles pour l'application. Pour autoriser l'identification Kerberos, l'application cliente de OAuthSD doit faire appel au contrôleur Authorize en réclamant ce scope.
Ainsi, la possibilité d'un SSO avec Kerberos reste sous le contrôle de l'administrateur du serveur OAuthSD et celui du concepteur de l'application cliente.

Un peu de technique...

Référence : https://docstore.mik.ua/manuals/php...

Création du principal kerberos
OAuthSD ouvre une connexion à la bibliothèque KADM5 avec les identifiants de l'administrateur du serveur Kerberos.
OAuthSD obtient un handle vers le gestionnaire KADM5 (ou false en cas d'erreur), dont on se servira pour interroger LDAP et obtenir les informations sur l'utilisateur, en particulier pour vérifier qu'il est authentifié sur le réseau.

/**
* Initialise la connexion avec le principal de l'administrateur du domaine $realm et retourne les informations sur un utilisateur $user.
* $user : nom de l'utilisateur,
* $admin_server : nom du serveur Kerberos sur le réseau local,
* $realm : Domaine d'identification,
* $admin_principal : Principal de l'administrateur du serveur Kerberos,
* $password : Mot de passe de l'administrateur du serveur Kerberos.
*/
function kerberos_getinfos( $user, $admin_server, $realm, $principal, $password ) {
$handle = kadm5_init_with_password($admin_server, $realm, $admin_principal, $admin_password);
$options = kadm5_get_principal($handle, $user . '@' . $realm);
kadm5_destroy($handle);
return $keys = array_keys($options);
}
?>

Télécharger

Identifier la machine locale

Lorsqu'une application demande au serveur OIDC une authentification pour un utilisateur final, elle s'adresse au contrôleur Authorize qui :
détermine l'adresse IP sur le réseau local de la machine depuis laquelle l'utilisateur s'est identifié sur Active Directory,
interroge le DNS pour obtenir le nom de la machine avec l'IP ( Ceci nécessite que tous les ordinateurs joints au domaine sont enregistrés au sein du DNS du réseau local, avec leur reverse renseigné ).

Authorize peut alors utiliser krb5 pour adresser la machine sur AD avec l'identifiant ..