Analyse et implémentation de cookies d'authentification unique en PHP

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 Lorsque vous utilisez des ressources, vous n'avez plus besoin de vous reconnecter pour vérification. J'espère que cet article sera utile à tout le monde.

Qu'est-ce que le SSO ?

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 actuel des applications d'entreprise, il y en a souvent. de nombreux systèmes d'application, tels que Taobao, Tmall, Love Taobao et d'autres produits tels que les systèmes de bureautique (OA), les systèmes de gestion financière, les systèmes de gestion de fichiers, les systèmes 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 : .

Confort d'utilisation : considéré 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 le même domaine) ?

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

Cookies partagés

Lorsque nos sous-systèmes sont tous en un Lorsque le navigateur se trouve sous le nom de domaine parent, nous pouvons installer le cookie sous le domaine parent, afin que les cookies sous le même nom de domaine puissent être partagés par les navigateurs. De cette manière, l'ID de session de l'utilisateur peut être obtenu grâce au cryptage du cookie et. algorithme de décryptage, 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 billets, nous adoptons actuellement cette méthode

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

a. L'utilisateur accède à un certain sous-système et constate que s'il n'est pas connecté, il sera invité à accéder à la page de connexion SSO
b. Déterminez si le SSO s'est connecté ; c. S'il est déjà connecté, accédez directement à l'adresse de rappel et renvoyez le ticket d'authentification ;
d S'il n'est pas connecté, l'utilisateur saisit correctement le nom d'utilisateur/le mot de passe, l'authentification passe et accède à l'adresse de rappel et renvoie l'authentification. ticket;
e.Le sous-système obtient le ticket et appelle SSO Obtenez l'ID utilisateur et d'autres informations, et laissez l'utilisateur 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 du 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 quelques données Au client, le champ

domaine dans Set-Cookie est utilisé pour indiquer le domaine où se trouve ce cookie.

Chestnut :

Lorsque nous visitons www.cookieexm.com, si le serveur ajoute Set-Cookie à l'en-tête de retour, si le domaine n'est pas spécifié, alors ceci le cookie sera par défaut Le domaine 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, 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.

Les éléments à noter dans les cookies

sont définis sur http uniquement

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

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 Pour implémenter l'authentification unique entre .b2 **.c1.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é et accédez à www.a1.a2 à titre d'exemple :

Regardez respectivement les effets de chaque étape :

Demande www.a1 .a2

www.a1.a2 reçoit la demande et vérifie s'il 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 saisit 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 à l'entreprise 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 attention

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

Comment empêcher la transmission d'informations le processus de transfert d'être falsifié

Comment faire en sorte que le système SSO fasse confiance au système de connexion et au système de liaison
Pour la première question, vous pouvez généralement utiliser une solution de cache distribué similaire à Memcached, qui peut non seulement fournir un mécanisme pour augmenter la quantité de données, mais aussi fournir un accès efficace

Pour la deuxième question, la méthode de signature numérique est généralement adoptée, soit via la signature de certificat numérique, soit via une méthode comme md5. Cela nécessite le système SSO pour fonctionner. Cryptage md5 sur les paramètres qui doivent être vérifiés lors du renvoi de l'URL de connexion. Et retournez 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 peut identifier si les informations ont été modifiées en vérifiant le jeton

Pour Le dernier problème peut être résolu via une liste blanche. Pour le dire simplement, seuls les systèmes figurant sur la liste blanche peuvent demander des relations de confiance en production. sur la liste blanche peuvent être dispensés de connexion.

Recommandations associées :

Principe d'authentification unique et mise en œuvre simple

Explication détaillée des méthodes de mise en œuvre de trois situations d'authentification unique SSO

Authentification unique UCenter/connexion synchrone/ exemples de déconnexion synchrone _PHP Tutorial

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!