Le schéma suivant est-il sécurisé pour les sessions distribuées sur plusieurs services?

Question

Je développe une application client/serveur qui communiquera sur Internet. Le serveur se compose cependant d'un certain nombre de services distincts, et je veux seulement que l'utilisateur doive s'authentifier une fois. Le schéma que j'ai en tête pour archiver ceci est d'avoir un service d'authentification central (sur une connexion cryptée où l'identité du serveur est authentifiée en premier) qui authentifie l'utilisateur et génère un ID de session "assez grand" en utilisant un générateur de nombres aléatoires. Pour chaque service auquel le client doit désormais accéder, il crée une nouvelle connexion, authentifie le serveur (en utilisant des certificats et SSL par exemple) puis envoie l'identifiant de session sécurisée pour prouver qu'il est authentifié pour la session donnée. Le service contacte le service d'authentification centralisée pour vérifier que la session est valide et active avant de répondre à d'autres demandes.

Y a-t-il des inconvénients à ce schéma par rapport à dire utiliser challenge/réponse sur l'identifiant de session ou les cookies d'authentification signés par le serveur? Tous les services sont approuvés, il n'est donc pas nécessaire de protéger contre un service (ab) en utilisant l'identifiant de session d'une connexion pour emprunter l'identité d'un utilisateur.

Answer 1

Une préoccupation majeure est que le client est en charge de la transmission de l'ID de session en tant que requête GET ou POST entre les serveurs, ce qui rend ce système vulnérable à Session Fixation. Par cette description, il n'est pas clair comment l'état de la session est transféré ou qui est en charge de cette information. Je suis d'accord que le cookie doit être un nombre aléatoire très grand appelé Cryptographic Nonce. Cette variable est utilisée comme clé pour accéder à l'état côté serveur. Dans le cas d'une session distribuée, la solution la plus simple consiste à disposer d'un serveur ou d'une base de données individuels pouvant être chargé de la gestion de l'état sur tous les domaines. Cela rend les choses plus faciles car un utilisateur peut travailler sur plusieurs domaines simultanément sans se soucier des conditions de course. Lorsqu'un serveur doit définir ou obtenir une variable de session, il envoie une requête au serveur de session commun.

Transférer un utilisateur d'un serveur à un autre sans introduire une vulnérabilité de fixation de session consiste à créer une utilisation unique "Identifiant de transfert", qui doit également être un non-cryptographique. Le serveur communal sait qu'un utilisateur a été marqué pour le transfert. Le navigateur client transmet cet "Identifiant de transfert" au nouveau serveur, le nouveau serveur recherche l'utilisateur sur la base de "l'identifiant de transfert", puis le nouveau serveur régénère un identifiant de session à utiliser pour ce domaine. Une méthode consiste à utiliser un gestionnaire de session traditionnel pour s'assurer que chaque serveur possède un identifiant de session unique. Le serveur individuel peut stocker des informations d'état pour lier cet identifiant de session avec l'état d'un utilisateur spécifique sur le système distribué.