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
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.
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