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.
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? –
+1 bonne question. – rook
@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