2010-12-02 38 views
1

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.Le schéma suivant est-il sécurisé pour les sessions distribuées sur plusieurs services?

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.

+0

L'ID de session est-il envoyé via un canal crypté? Existe-t-il un time-to-live pour un ID de session pour arrêter le forçage brutal des ID de session? Comment un service sait-il qu'un ID de session est valide? En vérifiant avec le service central ou une sorte de vérification de signature? –

+0

+1 bonne question. – rook

+0

@Mike, l'identifiant de session sera envoyé via un canal crypté tel que SSL, les services par satellite communiqueront avec le service d'authentification central pour vérifier qu'un identifiant de session est valide. – SoftMemes

Répondre

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

+0

Bonne réponse, merci! Dans mon schéma, le service d'authentification central va générer l'identifiant de session, et seulement après avoir authentifié avec succès le client - ce qui signifie que le schéma est à l'abri des attaques de fixation de session, non? – SoftMemes

+0

@Freed Dans votre description, vous avez dit: "... puis envoie l'identifiant de la session sécurisée pour prouver qu'il est authentifié pour la session donnée". Si cela est envoyé par le navigateur en tant que requête GET ou POST, il s'agit de la définition même de la fixation de session. – rook

+0

@Mike Samuel Cela me semble toujours être une fixation de session. – rook