Valider les demandes d'un utilisateur entre les serveurs

Question

Contexte: Je crée un serveur de fichiers. J'utilise Tomcat derrière le proxy inverse Nginx. J'ai un serveur principal qui héberge l'interface utilisateur et beaucoup de serveurs périphériques où j'espère stocker les fichiers téléchargés par l'utilisateur et les servir. C'est un stockage de fichiers privé, donc seul le téléchargeur de fichiers devrait pouvoir télécharger les fichiers téléchargés. Problème: J'authentifie les utilisateurs sur le serveur principal lorsqu'ils se connectent à leur compte en créant une session et en la conservant pour valider d'autres requêtes de la part des utilisateurs (tâches régulières). Cette information n'est pas propagée aux serveurs de périphérie, les serveurs de périphérie servent des fichiers à n'importe quelle demande. Ce n'est pas ce que je veux. Je veux autoriser les téléchargements uniquement pour le propriétaire du fichier.

Maintenant, ici j'essaie d'éviter le clustering Tomcat où les bords et les serveurs principaux configurent comme un cluster qui a des sessions distribuées. Le site est pris en charge par SSL. Existe-t-il un moyen de valider l'état de connexion d'un utilisateur lorsqu'une demande de téléchargement de fichier atteint un serveur Edge d'un utilisateur déjà connecté (créé une session) sur le serveur principal?

Answer 1

Je vois plusieurs approches que vous pouvez utiliser

Vous pouvez utiliser une forme de « l'authentification basée sur des demandes » ou un jeton d'accès aux ressources.

Authentification basée sur les revendications - vous pouvez utiliser par ex. un jeton JWT, qui doit contenir certaines informations nécessaires (identifiant utilisateur, identifiant de compte, autorisation, expiration, ..) et est signé par un secret partagé (entre le serveur principal et les serveurs de fichiers) ou par une clé privée du serveur principal.

L'avantage est que le serveur de périphérie peut valider le jeton en fonction du hachage ou de la signature sans contacter le serveur principal. Inconvénient, c'est qu'il doit y avoir de la logique pour décider si l'utilisateur a accès à la ressource demandée.

voir: https://jwt.io/

jeton d'accès à la ressource - cette approche qui est utilisée certains fournisseurs de stockage en nuage (AWS S3, IBM Object Storage, ...) - le site principal retourne une ressource URL avec quelques paramètres supplémentaires - par exemple compte, nonce, expiration, signature. Le serveur ressource (Edge) doit vérifier l'expiration et la signature et fournir ou refuser la ressource

L'avantage est que le serveur de périphérie ne se soucie pas de toute authentification et que l'authentification et l'autorisation sont complètement dans la portée du serveur principal. Le désavantage est que l'URL de ressource fournie doit avoir une durée d'expiration limitée.

voir: http://s3-expiry.50projects.com/

Note:

• placer la condition que le serveur de ressources ne peut pas communiquer avec le serveur principal, vous êtes effectivement incapable de vérifier si l'utilisateur est connecté, sauf en utilisant SAML SSO avec SLO (single logout) ou OIDC avec gestion de session