Single-Sign-On

Single Sign On SSO

• nginx-sso - Simple offline SSO for nginx
• https://github.com/heipei/nginx-sso/
• Article original : Single Sign On—You’re Probably Doing It Wrong

Exiger des utilisateurs qu’ils se connectent individuellement à tous les sites Web dont ils ont besoin pour leur travail est plus qu’ennuyeux :
Cela fait perdre beaucoup de temps et transforme le maintien des identifiants de connexion et des permissions en un cauchemar pour le personnel administratif.
Voyons si nous pouvons régler ce problème avec un service d’ouverture de session unique.

La mise en place de plusieurs services pour partager un login commun sans ré-authentification pour chaque demande ou lors du passage à une autre application peut sembler une tâche assez complexe à première vue. Et bien que nous ayons bien sûr certaines choses à considérer, la solution finale n’a pas besoin d’être trop complexe.

Le concept de base d’un service d’authentification unique - SSO pour short - est de permettre à un utilisateur de se connecter (authentifier) une fois lors de la demande de la première URL protégée, indépendamment du service visité, et de maintenir cet état indépendamment de tout autre service utilisé ensuite.
Lorsqu’il est configuré comme proxy, c’est le travail du SSO de s’assurer que l’utilisateur est authentifié avant de permettre que la demande soit transmise au service réel, et de fournir à l’application des informations d’identité afin qu’elle ait un moyen de savoir qui est son utilisateur.

Un SSO implique que la gestion des comptes utilisateurs est centralisée. Cela présente certains avantages pour le personnel administratif, car ils n’ont à créer qu’un seul compte d’utilisateur pour toutes les applications. Il évite également la nécessité de synchroniser les détails de connexion entre les différentes plates-formes et de tenir compte de leurs règles différentes pour les mots de passe, les noms d’utilisateur et autres informations requises.

L’authentification centralisée profite également à l’utilisateur final : Plus de changement de mot de passe pour des applications individuelles avec des exigences différentes, et la nécessité de se rappeler où le mot de passe a déjà été changé et où l’ancien mot de passe est encore valide. Parce que, soyons réalistes, tout le monde n’adhère pas à la règle de ne pas utiliser le même mot de passe pour plusieurs services, de toute façon. Et bien sûr, il n’est pas nécessaire de se connecter encore et encore, juste pour ouvrir toutes les applications nécessaires pour la journée de travail.

D’autre part, le fait de s’appuyer sur un seul service transforme l’authentification en un point de défaillance unique - SPoF (Single Point of Failure). Si le service SSO n’est pas disponible, aucune connexion ne peut être effectuée pour n’importe quelle application. Pour nous et du point de vue de l’architecture du système, cela signifie que la disponibilité du serveur SSO doit être notre priorité absolue lors de la planification de l’exploitation quotidienne.

Cela semble cependant loin d’être un nouveau problème, et il y a de fortes chances que vous ayez ou ayez déjà eu un autre point unique de défaillance dans votre entreprise ou réseau : un serveur de base de données partagée, par exemple, ou la liaison montante unique vers Internet depuis votre bureau, ce commutateur ou routeur de réseau, ou même le serveur de fichiers unique où tous les documents sont stockés.

Heureusement, il existe déjà de nombreuses solutions possibles pour atteindre une haute disponibilité : Qu’il s’agisse de simples redondances, de basculements ou de clusters, tout ce que nous devons décider, c’est lequel correspondrait le mieux à nos besoins concrets.

Comme les avantages l’emportent nettement sur les problèmes potentiels, il est temps de se lancer dans le développement de notre solution d’authentification unique.

Authentification, autorisation ou les deux ?

Certes, l’abréviation commune “Auth” n’est pas très spécifique. Est-ce que cela signifie Authentification, Authentification, Autorisation, ou même les deux ? Et de laquelle avons-nous besoin dans notre contexte SSO ? Pour compliquer les choses, la réponse surprenante est : “Ça dépend”.

L’authentification, c’est-à-dire le fait de vérifier qu’une personne est bien celle qu’elle prétend être, est habituellement une condition préalable à l’accès. Un tel processus peut être mis en œuvre de façon assez générique et est bien compris. Déterminer si cette personne, après avoir été authentifiée, est maintenant autorisée à effectuer une certaine action ou si elle est autorisée à récupérer les données demandées est une tâche plus complexe.

Bien que les constructions de base des LCA (listes de contrôle d’accès) puissent être gérées de façon générique, des restrictions plus fines peuvent également être nécessaires. Par exemple, l’accès à un profil a été accordé par la LCA, mais la quantité de données affichées varie selon le type d’utilisateur. En particulier dans les applications basées sur CRUD, il peut être très difficile de déterminer, lors de l’enregistrement, quelle partie du profil a été modifiée et si l’utilisateur actuel avait réellement le droit de modifier ce champ. Essayer de trouver une solution générique pour la gestion et le mappage de ces types de permissions dans l’application est susceptible de causer des nuits blanches pour toutes les personnes impliquées.

Ainsi, pour ne pas se noyer dans la complexité, le SSO devrait se limiter à offrir l’authentification. Et peut-être vérifier si l’utilisateur est autorisé ou non à utiliser l’application en question pour détecter rapidement les violations de la politique. Toute autorisation supplémentaire doit être déléguée à la demande elle-même.

Avant de développer un nouveau logiciel, il est toujours bon de regarder les solutions préexistantes. Peut-être n’avons-nous pas besoin de programmer quoi que ce soit ?

OAUTH ?

Bien sûr, il existe différentes approches techniques du SSO, ainsi que de nombreuses solutions commerciales. Lorsqu’ils sont chargés d’implémenter eux-mêmes un service de SSO “simple”, de nombreux développeurs considèrent OAUTH comme la voie à suivre. OAUTH a pour objectif d’être un “protocole ouvert pour permettre une autorisation sécurisée dans une méthode simple et standard à partir d’applications web, mobiles et de bureau”. Comme l’énoncé de mission met clairement l’accent sur l’autorisation, ce n’est probablement pas ce dont nous avons besoin, mais jetons un coup d’œil quand même : OAUTH a été conçu pour permettre aux utilisateurs d’accorder l’accès à la fonctionnalité de l’application de fourniture à un tiers sans révéler les informations d’identification de l’utilisateur. Un aspect très important dans la conception d’OAUTH est que le logiciel tiers n’est pas digne de confiance, du point de vue de l’application qui fournit l’application.

Au-delà de l’authentification elle-même, nous ne voulons pas accéder aux fonctionnalités du serveur SSO, et encore moins que l’utilisateur en ait le contrôle. Comme cela va conceptuellement dans la direction opposée à celle où nous essayons d’aller, OAUTH ne peut pas être la réponse. Cela nous évite de nous pencher sur ses aspects techniques et nous pouvons vérifier le prochain candidat.

SAML ?

Suivant sur la liste des choses que Google retourne habituellement lorsque nous sommes à la recherche de SSO et PHP est SAML - le langage de balisage d’assertion de sécurité. SAML a été développé par le consortium OASIS (OASIS signifie “Organization for the Advancement of Structured Information Standards”). OASIS a publié un large éventail de normes, comme l’Open Document Format utilisé par LibreOffice ou le format Docbook utilisé par le manuel PHP. SAML existe depuis 2001 et est utilisé par de nombreux grands acteurs du marché des entreprises. Il s’agit d’un standard pour l’échange de données d’authentification et d’autorisation entre domaines de sécurité. Le puissant protocole basé sur XML utilise des jetons de sécurité contenant des assertions pour transmettre des informations sur un utilisateur final entre un fournisseur d’identité et un service.

Cela n’a pas seulement l’air assez complexe, cela vient avec beaucoup de frais généraux techniques si tout ce que nous voulons est un login partagé.

Cela ne devrait-il pas être assez simple ?

Approche naïve

Prenons du recul et réévaluons notre problème. Techniquement parlant, notre objectif est de faire en sorte que de multiples applications sachent que l’utilisateur est connecté et authentifié. Nous ne nous soucions pas de l’autorisation à ce stade.

En supposant que toutes les applications sont écrites en PHP et sont hébergées sur le même réseau ou même sur la même machine physique, la solution la plus simple et la plus simple pourrait être d’utiliser une session partagée.

Sauf que ça ne marche pas : Dès qu’il y a des valeurs supplémentaires spécifiques à l’application et des objets potentiellement sérialisés stockés dans la session PHP, l’idée s’effondre. Puisque, par définition, toutes les données de la session sont partagées, chaque application doit être capable de lire et de travailler avec la structure de données donnée. Nous serions limités aux valeurs scalaires si nous ne voulions pas que des objets de classe incomplets soient créés lors de la désérialisation.

Mais c’est en fait le moindre de nos problèmes. Si nous devions mettre en œuvre cette mesure, nous aurions un grave problème de sécurité : Nous avons fourni à une application les moyens de modifier l’état de session d’une application sans rapport ! C’est un gros problème et c’est définitivement une interdiction. Pour corriger cela, il faudrait séparer les informations d’authentification de la session d’application. Cela signifie que nous aurions à traiter deux sessions dans un processus PHP. Malheureusement, l’extension de session PHP standard ne supporte pas cela et nous devrions implémenter nous-mêmes toute la gestion des sessions.

Ce pourrait être une tâche amusante à faire, mais ne peut guère être considérée comme une solution simple. Et le partage d’une session a un autre inconvénient potentiel : Que se passe-t-il si toutes les applications ne sont pas écrites en PHP ?

Les sessions partagées sont terminées.

Jeton Web JSON

Toutes les approches centrées sur le serveur ont échoué pour diverses raisons, peut-être devrions-nous inclure le navigateur dans le jeu et utiliser sa capacité à stocker des informations pour nous. Étant donné que nous ne pouvons pas simplement faire confiance à tout ce qui est stocké sur le client sous forme de texte brut parce qu’il peut être manipulé, nous devons trouver un moyen sûr de stocker notre résultat d’authentification dans le navigateur.

L’un de ces moyens serait un JSON Web Token, ou JWT en abrégé. Définies dans la RFC 7519, les TJWT sont une norme ouverte qui définit un moyen compact et autonome de transmission d’informations entre deux parties sous la forme d’un objet JSON. Les informations fournies peuvent être vérifiées en vérifiant une signature numérique et devraient donc être à l’abri de toute manipulation. Les TJWT peuvent être signés soit en utilisant un secret au sein de l’algorithme HMAC, soit en utilisant une paire de clés publiques/privées. Tout ce joli cryptage est en fait plutôt inutile si un attaquant peut simplement capturer le trafic réseau et extraire le jeton à cause d’un transport non protégé. Pour que cette approche fonctionne, nous devons compter sur HTTPS jusqu’au bout. Heureusement, cela ne devrait pas être un problème, car HTTP est en train de mourir de toute façon.

La page Web sur JWT mentionne explicitement l’authentification comme un scénario d’utilisation commune, avec une connexion unique. Il y a des implémentations client pour pratiquement tous les langages ; PHP a même différentes solutions alternatives à choisir.

Ça a l’air bien ! C’est peut-être la voie à suivre ?

Obtenir toutes les informations sur l’utilisateur sans qu’il soit nécessaire d’appeler une API ou d’interroger une source de données supplémentaires est certainement un plus. Mais comment faire passer l’information du navigateur au serveur ? Tandis que JWT définit les propriétés requises dans la chaîne JSON, il n’y a pas de norme officielle pour l’envoyer. Une façon recommandée semble être l’utilisation d’un en-tête d’autorisation personnalisé :

Autorisation : Porteur <token>>>Porteuse

Bien qu’un tel en-tête puisse facilement être ajouté à toute requête JavaScript ou à tout appel API via http, il semble qu’il n’y ait aucun moyen de faire en sorte que le navigateur ajoute un tel en-tête à la requête sortante par lui-même. Et pourquoi y en aurait-il, étant donné que c’est pour cela que les cookies ont été conçus à l’origine. Et, bien sûr, le manuel de JWT mentionne également les cookies comme une option valide. Les cookies, cependant, sont limités dans leur taille, ce qui peut s’avérer problématique, selon le niveau de détail des informations utilisateur. D’autre part, si la taille des données dépassait les restrictions de taille des cookies, les frais généraux de trafic pour chaque demande seraient d’une ampleur considérable.

Et ce n’est pas tout : Conceptuellement, les JWTs sont comme un cache distribué. Lorsque vous utilisez JWT pour stocker des données d’authentification sur le client, le serveur SSO n’est plus jamais dérangé, c’est-à-dire jusqu’à l’expiration du JWT. C’est bien sûr par intention et c’est tout à fait logique pour les TJWT. Mais si vous voulez changer les permissions d’accès, désactiver un compte ou simplement ajouter de nouvelles valeurs, vous devrez attendre que le jeton ait expiré.

Ceci, avec tous les frais généraux d’analyse et de signature, ressemble encore une fois à l’opposé d’une solution simple.

Jetons d’utilisateur et rappels

Cela nous laisse l’idée d’un jeton d’utilisateur ou d’un identifiant et d’un appel API de l’application à notre service SSO pour obtenir l’information réelle de l’utilisateur. Le processus pourrait être simple : Une fois l’utilisateur authentifié, un jeton utilisateur ou un identifiant est généré par le service SSO et stocké sous la forme d’un cookie régulier et partagé sur le client. Equipé de ce jeton, l’application pourrait appeler une API fournie par notre service SSO pour récupérer des informations supplémentaires sur l’utilisateur actuel.

Alors que l’idée générale d’un simple jeton de type session à stocker sur le client sonne bien, le reste semble terriblement réinventer OAUTH. Cela signifie également que nous devons fournir cette API supplémentaire et définir les structures de données, en satisfaisant les besoins de toutes les applications que nous prévoyons de protéger. Et nous devons faire en sorte que chaque application appelle notre API pour obtenir l’information.

Donc, peut-être qu’exiger des rappels n’est pas encore une bonne solution.

Éviter les rappels au travail

En séparant vraiment les préoccupations, l’application protégée ne devrait pas être au courant de l’installation du proxy SSO. Pour ce faire, le BSP disposerait de son propre jeton de session, tel que décrit au dernier paragraphe, mais utiliserait une approche par procuration pour injecter des informations supplémentaires pour l’application dans la demande avant de la transmettre.

De cette façon, l’application obtiendra ce dont elle a besoin sans faire d’appels API et le proxy SSO sera responsable de la sécurité à tout moment et en toute transparence. Cela sonne bien, mais aussi assez compliqué ? En fait, ce n’est pas le cas, comme le démontreront (enfin) les exemples suivants.

Commençons par le serveur web de l’application. Comme nous avons besoin d’un serveur http capable de gérer le routage dynamique et le proxying, nous utiliserons NGINX, Redis et quelques LUA simples :

Liste 1

server {

    # ...

    server_name application.example.com;

    location / {
        lua_code_cache off;
        access_by_lua_file /var/www/lua/access.lua;

        proxy_set_header X-Real-IP  $remote_addr;
        proxy_pass https://application.local/;
    }
}

Le serveur Web accessible au public sur “application.exemple.com” exécutera le script lua access.lua pour déterminer si la demande peut et doit être transmise à l’application nommée serveur d’application.local dans cet exemple. Il devrait être évident que l’accès à ce serveur devrait être limité au seul travail via le proxy SSO devant lui.

La logique principale du SSO est implémentée dans le script access.lua du Listing 2.

Liste 2

local uuid = ngx.var.cookie_uuid;
local sso = 'https://sso.example.com/';

if not uuid then
     ngx.redirect(sso);
end

local redis = require "resty.redis"
local red = redis:new()
red:set_timeout(1000) -- 1 sec
local ok, err = red:connect("127.0.0.1", 6379)
if not ok then
    ngx.say("failed to connect: ", err)
    return
end

local res, err = red:get(uuid)
if not res then
    ngx.redirect(sso);
end

if res == ngx.null then
    ngx.redirect(sso);
end

ngx.header["uuid"] = nil
ngx.req.set_header("X-USER-INFO", res);

Le code ci-dessus vérifie si un cookie UUID est configuré et, le cas échéant, si les données correspondantes peuvent être trouvées dans la base de données des clés Redis. Si cela n’a pas fonctionné ou si aucun cookie n’a été mis en place, l’utilisateur sera redirigé vers le service SSO disponible sur “sso.example.com”.

Dans les cas où le cookie a été configuré et qu’il y a des données correspondantes trouvées dans Redis, il sera injecté dans la requête sous la forme d’un en-tête personnalisé supplémentaire nommé X-USER-INFO. Et la demande sera retournée à Nginx, qui à son tour la transmettra à notre application à l’adresse’application.local’.

Notre accès.lua ci-dessus repose sur le cookie UUID et sur Redis pour conserver les données de l’utilisateur. Pour que cela fonctionne, les données de l’utilisateur doivent être stockées dans Redis et le cookie doit être configuré après une connexion réussie. L’extrait suivant (liste 3) du login montre à quoi cela ressemblerait en gros dans le code source.

Liste 3

<?php

// ...

if ($this->credentialsAreValid()) {

    $uuid = trim(file_get_contents('/proc/sys/kernel/random/uuid'));
    $data = $this->getUserData();
    $ttl  = 3600;

    $redis = new Redis();
    $redis->connect('127.0.0.1', 6379);

    $redis->set($uuid, $data);
    setcookie("uuid", $uuid, time() + $ttl, '/', 'example.com', true, true);

    // ...

}

// ...

Pour compléter l’installation, nous avons bien sûr encore besoin de configurer les deux hôtes restants, “sso.example.com” ainsi que “application.local”. Les deux sont plutôt des configurations de serveur web PHP standard et ne fournissent donc rien d’intéressant pour l’instant. Des exemples peuvent être trouvés dans le matériel d’accompagnement de cet article, pour ceux qui sont intéressés.

En supposant que nous implémentons un mécanisme d’authentification réel sur sso.example.com, nous avons maintenant un système d’authentification unique pour toutes les applications de notre domaine.

L’envoi des données utilisateur sous forme d’en-tête n’est bien sûr qu’un moyen de fournir les données. Vous êtes totalement libre d’implémenter n’importe quel format adapté à vos besoins. Par exemple, nous pourrions améliorer le code lua pour créer un jeton web JSON à transmettre à l’application interne lors de la connexion, satisfaire certains BASIC HTTP Auth, ou émuler un LDAP ou même un DN de certificat TLS.

Certificats côté client TLS

En parlant de certificats : si vous voulez franchir une étape supplémentaire, vous pourriez envisager d’éviter complètement le processus de connexion en déployant des certificats côté client.

Inconnus de beaucoup, les certificats TLS peuvent fonctionner dans les deux sens : d’une part, un serveur s’authentifie auprès du navigateur et, d’autre part, un client s’authentifie auprès du serveur.

Pour que ce processus fonctionne, vous devez établir votre propre autorité de certification (AC) et fournir à l’utilisateur un certificat signé par cette autorité. Vous pouvez également créer un portail d’enregistrement et utiliser l’élément de formulaire HTML5’keygen’ pour que le navigateur crée une clé et signe le CSR généré. Cependant, le développement d’un tel portail n’entre pas dans le champ d’application de cet article.

Si votre certificat client signé par l’autorité de certification est installé dans le navigateur, vous pouvez en exiger l’utilisation en activant la fonctionnalité correspondante dans NGINX avec seulement quelques changements à toute configuration de serveur compatible TLS. Voir la liste 4.

Liste 4

server {

    // ...

    ssl_client_certificate /etc/ssl/ca/certs/ca.crt;
    ssl_crl /etc/ssl/ca/private/ca.crl;
    ssl_verify_client on;

    error_document 403 = @register;

    location / {
        fastcgi_param  VERIFIED $ssl_client_verify;
        fastcgi_param  DN $ssl_client_s_dn;

        // ...
    }

    location @register {
        return 302 https://register.example.com;
    }

}

La solution parfaite ?

Strictement parlant, seule une approche proxy peut fournir une véritable signature unique. Seule la première demande à l’un ou l’autre service est de demander à l’utilisateur de se connecter, à partir de ce moment-là, toutes les demandes sont déjà authentifiées, quelle que soit l’application suivante. Toute autre solution peut, bien sûr, utiliser un service partagé pour l’authentification, mais nécessitera néanmoins des connexions individuelles. Que ce login soit effectué avec un nom d’utilisateur et un mot de passe ou un certificat est presque un détail d’implémentation.

Que la solution de SSO utilisant un proxy puisse ou non fonctionner pour vous dépend fortement de vos besoins et de votre situation en général. Comme toujours au sein de l’informatique, il n’existe pas de solution parfaite ou universelle. Vous devez peser les coûts et les avantages individuels.

Pour que l’approche par procuration fonctionne, tout doit être acheminé par l’intermédiaire de la procuration. Bien que tous les services puissent avoir leur propre nom d’hôte, individuel et unique, en raison du cookie utilisé pour le suivi dans la solution démontrée ici, ils doivent tous résider dans le même domaine. Sinon, le navigateur ne l’enverra pas et nous n’avons pas de moyen générique de le configurer pour d’autres domaines.

Les certificats côté client n’ont pas de restriction de nom de domaine car ils n’utilisent pas de cookies. Mais ils sont liés au navigateur ou même au système d’exploitation, ce qui rend le partage de l’appareil beaucoup plus difficile s’il n’est pas fourni avec un environnement multi-utilisateurs ou la gestion des profils individuels.