Sécurité dans le système d'applications Web distribuées

Question

J'ai un ensemble de trois systèmes d'application Web - A, B & C qui sont utilisés pour entretenir mon application. Le système A possède la logique métier principale et stocke également les données utilisateur/compte pour l'ensemble de l'application. Les systèmes B & C sont nécessaires pour fournir des fonctionnalités supplémentaires à l'application. Je pensais à un mécanisme de sécurité où un utilisateur U se connecte au système principal A et le système crée un jeton de sécurité pour la session en cours qui sera nécessaire pour authentifier une demande de l'utilisateur U aux autres systèmes B & C. Au moment où l'utilisateur se connecte au système A, il génère en interne le jeton et envoie le jeton xyz aux sous-systèmes B & C. Maintenant, l'utilisateur U envoie une requête aux sous-systèmes B & C avec une valeur valide. jeton, l'utilisateur aura accès aux ressources. Mais alors, je ne suis pas sûr si c'est la meilleure approche ou même une bonne. Donc, je suis un peu confus au sujet du workflow complet et toute aide à cet égard sera très appréciée.

Je développe en Java et donc tout module qui le gère déjà économisera beaucoup de mon temps de développement. Guidez-moi s'il-vous-plaît.

Answer 1

Ce modèle que vous décrivez est une forme d'entiercement de confiance, où plusieurs clients font confiance à un tiers pour gérer l'authentification de l'utilisateur.

Voir le système de sécurité distribué Kerberos.

Le protocole Kerberos et sa mise en œuvre application web, Stanford webAuth, ont quelques avantages par rapport à ce que vous décrivez:

• Il n'y a pas besoin d'envoyer le jeton de A à B + C quand un utilisateur se connecte Au lieu de cela, A (le «KDC» en termes de Kerberos) partage un secret avec B (un «serveur Kerberized») et un avec C seulement lors de la configuration initiale de la relation d'approbation.
• Le jeton ne peut pas être intercepté car il n'est jamais envoyé en clair de A à l'utilisateur.

Si vous n'avez pas besoin d'authentification Kerberos à part entière, qui peut être complexe à mettre en œuvre, je vous encourage un modèle comme celui-ci:

• utilisateur Joe authentifie à A, en utilisant de préférence un défi- protocole de réponse qui ne concerne pas l'envoi de mot de passe de Joe à A
• Un signe cryptographiquement nom d'utilisateur de Joe, l'heure actuelle, et des ordures
• B et C généré aléatoirement accepter les utilisateurs dans le délai prescrit qui peut présenter des paquets signés par A contenant leur nom d'utilisateur et le heure appropriée

Il s'agit d'un protocole d'authentification de jeton de base. C'est défectueux de plusieurs façons, mais c'est toujours mieux que d'envoyer le mot de passe de l'utilisateur.

Answer 2

Cet arrangement fonctionnera également: Vous pouvez rediriger toutes les demandes au serveur A, B et C d'abord au serveur A pour l'authentification car il a toutes vos données relatives à l'utilisateur. Maintenant, une fois que la demande a été authentifiée (par quelle méthode vous préférez), et dans votre logique métier, vous devez effectuer un appel INTERNE entre les serveurs. Pour cela, vous pouvez utiliser des utilisateurs internes qui, au moment du déploiement, sont créés sur chacun des serveurs et leur jeton d'autorisation est stocké dans un portefeuille. Récupérer le jeton d'authentification pour cet utilisateur interne à partir du portefeuille et lancer l'appel, l'autre serveur autorisera l'utilisateur. Remarque: Si jamais vous avez besoin de savoir qui est l'utilisateur réel effectuant cette opération, alors cette information ne peut pas être dérivée du jeton d'authentification car le jeton est de l'utilisateur interne. Dans ce cas, vous pouvez passer le nom d'utilisateur actuellement connecté dans l'en-tête d'autorisation http.