Analyse de connexion aux cookies SSO et implémentation en PHP

Qu'est-ce que l'authentification unique ?

Single Sign-On SSO (Single Sign-On) fait partie de la gestion des identités. Une définition plus populaire de SSO est la suivante : SSO signifie que le même utilisateur qui accède à des ressources protégées dans différentes applications sur le même serveur n'a besoin de se connecter qu'une seule fois, c'est-à-dire qu'après avoir réussi la vérification de sécurité dans une application, il peut ensuite accéder aux ressources protégées. dans d'autres applications. Lors de l'accès aux ressources, il n'est pas nécessaire de se reconnecter pour vérification

Objectif du SSO :

Dans l'environnement d'application d'entreprise actuel, il existe souvent de nombreux systèmes d'application, tels que Taobao, Tmall, Aitaobao et d'autres produits tels que le système de bureautique (OA), le système de gestion financière, le système de gestion de fichiers, le système de requête d'informations, etc. Ces systèmes d'application servent à la construction de l'information de l'entreprise et apportent de bons avantages à l'entreprise. Cependant, il n’est pas pratique pour les utilisateurs d’utiliser ces systèmes d’application. Chaque fois qu'un utilisateur utilise le système, il doit saisir son nom d'utilisateur et son mot de passe pour vérifier son identité ; différents systèmes d'application ont des comptes d'utilisateur différents, et les utilisateurs doivent mémoriser plusieurs ensembles de noms d'utilisateur et de mots de passe en même temps. Ce problème est particulièrement important pour les entreprises disposant d'un grand nombre de systèmes d'application et d'un grand nombre d'utilisateurs. La cause du problème n'est pas une erreur dans le développement du système, mais un manque de planification globale et d'une plate-forme de connexion utilisateur unifiée. L'utilisation de la technologie SSO peut résoudre les problèmes ci-dessus

Avantages du SSO :

. Pratique pour les utilisateurs : du point de vue de l'utilisation réelle de l'utilisateur

Lorsque les utilisateurs utilisent le système d'application, ils peuvent se connecter une fois et l'utiliser plusieurs fois. Les utilisateurs n'ont plus besoin de saisir des noms d'utilisateur et des mots de passe utilisateur à chaque fois, ni de mémoriser plusieurs ensembles de noms d'utilisateur et de mots de passe utilisateur. Une plate-forme d'authentification unique peut améliorer l'expérience utilisateur lors de l'utilisation du système d'application.
Pratique pour les administrateurs : du point de vue de la maintenance et de la gestion quotidiennes

De nombreuses grandes sociétés Internet disposent désormais de nombreuses applications, par exemple, voici une capture d'écran de Taobao :

Tmall Juhuasuan Toutiao et d'autres sont des applications différentes, et certaines utilisent même des noms de domaine complètement différents, mais tous les utilisateurs enregistrés sur Taobao utilisent le même ensemble de noms d'utilisateur et de mots de passe, si vous Basculez directement entre ces systèmes et ne pouvez pas synchroniser le statut de connexion, l'expérience sera très mauvaise. Comme autre exemple, de nombreuses entreprises disposent de nombreux systèmes internes, tels que des systèmes RH, des systèmes financiers, des systèmes de présence, etc. Si les employés se connectent à un système et doivent se connecter pour passer à un autre système, ce sera très inconfortable.

Sur cette base, le SSO (Single Sign On) est né. Bien entendu, il existe de nombreuses façons de répondre à cette exigence. L'utilisation de cookies est l'une des méthodes les plus simples. Le principal problème à résoudre est le suivant : les cookies ne peuvent pas être transférés d'un domaine à l'autre (pas). dans la même application) ?

Donc, si vous n'êtes pas familier avec le mécanisme des cookies, veuillez d'abord le rechercher sur Google et comprendre pourquoi les cookies sont conçus pour ne pas traverser les domaines et d'autres problèmes connexes.

Les administrateurs système n'ont besoin que de maintenir un ensemble unifié de comptes d'utilisateurs, ce qui est pratique et simple. En revanche, les administrateurs système devaient auparavant gérer de nombreux ensembles de comptes d'utilisateurs. Chaque système d'application dispose d'un ensemble de comptes d'utilisateurs, ce qui non seulement entraîne des inconvénients pour la gestion, mais est également sujet à des failles de gestion.

Simplifier le développement du système d'application : considérer du point de vue de l'expansion des applications

Lors du développement d'un nouveau système d'application, vous pouvez utiliser directement le service d'authentification utilisateur de la plate-forme d'authentification unique pour simplifier le développement processus. La plateforme d'authentification unique réalise l'authentification unique en fournissant une plateforme d'authentification unifiée. Par conséquent, le système d’application n’a pas besoin de développer de procédures d’authentification des utilisateurs. ​
Comment y parvenir ?

SSO dispose des moyens suivants pour mettre en œuvre les

Cookies partagés

Lorsque nos sous-systèmes sont tous sous un nom de domaine parent, nous pouvons installer des cookies sous le domaine parent , les cookies sous le même nom de domaine peuvent être partagés par les navigateurs, de sorte que l'ID de session de l'utilisateur puisse être obtenu via l'algorithme de cryptage et de décryptage des cookies, réalisant ainsi le SSO.

Cependant, nous avons découvert plus tard que cette méthode présente plusieurs inconvénients :
a. Tous les systèmes avec le même nom de domaine peuvent obtenir le SessionID, qui est facile à modifier et dangereux
 ; b. Le domaine multiplateforme ne peut pas être utilisé.

vérification des tickets, nous adoptons actuellement cette méthode

Cette implémentation de SSO comporte les étapes suivantes :

a . un certain sous-système et constate que s'il n'est pas connecté, l'utilisateur sera guidé pour accéder à la page de connexion SSO
b. Déterminez si le SSO s'est connecté
c. directement à l'adresse de rappel, et renvoie le ticket d'authentification ;
d. S'il n'est pas connecté, l'utilisateur saisit correctement le nom d'utilisateur/mot de passe, le mot d'authentification passe à l'adresse de rappel et renvoie le ticket d'authentification
e ; Le sous-système obtient le ticket, appelle SSO pour obtenir les informations sur l'UID de l'utilisateur, etc., et permet à l'utilisateur de se connecter après succès.

Comme mentionné précédemment, la manière de mettre en œuvre le SSO via les cookies concerne principalement la manière de résoudre les problèmes inter-domaines. Parlons d’abord de l’attribut de domaine dans Set-Cookie.

Domaine Cookie

Afin de permettre au protocole Http de maintenir le contexte dans une certaine mesure, le serveur peut ajouter Set-Cookie à l'en-tête de réponse pour écrire certaines données au client , Set- Le champ

domaine dans le cookie est utilisé pour indiquer le domaine où se trouve le cookie.

Chestnut :

Nous visitons www.cookieexm.com Si le serveur ajoute Set-Cookie à l'en-tête de retour, et si le domaine n'est pas spécifié, le domaine par défaut de ce cookie est www. .cookieexm.com, c'est-à-dire que le client renverra ce cookie au serveur uniquement lors de sa visite sur www.cookieexm.com.
Si nous spécifions le domaine comme .cookieexm.com, alors le client peut renvoyer des cookies lors de l'accès aux noms de domaine suivants : www.cookieexm.com www1.cookieexm.com a.cookieexm.com ***.cookieexm.com.

Nous tirons donc une conclusion : le client correspond au domaine du cookie depuis la fin. Avec cette base, nous pouvons mettre en œuvre notre connexion SSO.

Ce qui doit être noté dans le cookie

est défini sur http uniquement

Les informations de connexion (telles que les tickets ou les noms d'utilisateur) doivent être cryptées

Les cookies ne peuvent pas stocker de données privées

Solution spécifique

Supposons que nous ayons besoin du sous-système suivant **.a1.a2 **.b1.b2 **.c1 Pour implémenter l'authentification unique entre .c2, nous avons d'abord besoin d'un système d'authentification (sso.s1.s2) spécifiquement pour l'authentification unique. Supposons que le système n'est actuellement pas connecté. Prenons www.a1.a2 comme exemple :

Regardez respectivement les fonctions de chaque étape :

Demande www.a1 .a2

www.a1.a2 reçoit la demande et vérifie si elle porte le cookie de connexion S'il ne s'est pas encore connecté, il redirigera vers le centre d'authentification SSO
SSO fournit. une fenêtre de connexion, et l'utilisateur entre le nom d'utilisateur et le mot de passe. Le système SSO vérifie le nom d'utilisateur et le mot de passe

Cette étape est clé Si la connexion est réussie, le cookie du système SSO est d'abord placé sur le client, en même temps que l'authentification de l'utilisateur ; les informations sont transmises à la partie commerciale par redirection. Notez que ce transfert ne peut évidemment pas être transmis via des cookies (différents domaines), généralement via une chaîne de requête cryptée.

Le système de vérification du côté commercial reçoit les informations d'authentification SSO puis s'authentifie
Une fois que le côté commercial a réussi l'authentification, il écrit le cookie du résultat de l'authentification dans .a1.a2. l'authentification SSO est terminée
Redirection vers le système métier www.a1.a2 D'après la conclusion précédente, tous les systèmes métier se terminant par .a1.a2 peuvent utiliser ce cookie authentifié

réponse

Remarque :

Le système d'authentification de l'entreprise peut ne pas exister. Certains systèmes qui ne sont pas trop sensibles peuvent être redirigés directement de l'autorisation SSO vers le système de l'entreprise et y apporter les informations d'authentification SSO.

Suite à ce qui précède, à ce moment, si l'utilisateur accède à l'application www.b1.b2, comme le montre la figure ci-dessous :

est le identique à l'accès à www.a1.a2 La différence est que nous n'avons plus besoin de saisir le nom d'utilisateur lors de la redirection vers l'autorisation SSO, car sso.s1.s2 a déjà des cookies à ce moment et utilise directement la vérification des cookies.

Ce qui précède est un simple système de connexion basé sur des cookies.

Plusieurs de ces problèmes doivent être résolus avec concentration

Comment stocker efficacement une grande quantité de données de confiance temporaires

Comment empêcher la falsification du processus de transfert d'informations
Comment faire en sorte que le système SSO fasse confiance au système de connexion et au système Bintang
Pour le premier problème, vous pouvez généralement utiliser une solution de cache distribué similaire à Memcached, qui peut non seulement fournir un mécanisme pour un volume de données évolutif, mais également fournir accès efficace

Pour le troisième problème Deux questions sont généralement utilisées, soit via des signatures de certificat numérique, soit via des méthodes comme md5. Cela nécessite que le système SSO crypte les paramètres qui doivent être vérifiés avec md5 lors du retour. l'URL de connexion et la renvoyer avec le jeton. Lorsque le système qui doit être connecté vérifie enfin la relation de confiance, le jeton doit être transmis au système SSO. Le système SSO peut identifier si les informations ont été modifiées par. vérification du jeton

Pour la dernière question, vous pouvez passer Pour faire simple, seuls les systèmes de la liste blanche peuvent demander des relations de confiance en production De même, seuls les systèmes de la liste blanche peuvent être exemptés de connexion.

Pour plus d'articles liés à l'analyse et à la mise en œuvre de la connexion aux cookies SSO en PHP, veuillez faire attention au site Web chinois de PHP !