J'ai une application Web ASP.NET qui interagit avec les services de WCF. L'application Web et les services de WCF sont sous mon contrôle. L'application Web ASP.NET utilise une implémentation personnalisée du modèle fournisseur d'adhésion ASP.NET (avec des mots de passe stockés sur un formulaire haché) pour authentifier les utilisateurs qui se connectent à l'application Web. L'application Web ASP.NET et les services WCF ont accès à la même base de données d'adhésion.
Étant donné que les utilisateurs fourniront leur mot de passe une seule fois, et je ne veux pas avoir à stocker leurs mots de passe nulle part ou les ennuyera en leur demandant de manière répétée de réapprovisionner leur mot de passe, j'ai besoin d'un mécanisme approprié pour authentifier les utilisateurs avec le WCF. Services.
Basé sur d'autres questions et réponses que j'ai vues, je envisage une approche "Session de connexion", où une session de connexion sera créée dans la base de données de membre personnalisée lorsque l'utilisateur se connecte initialement à l'application Web, avec le Session de connexion identifiée par un GUID et expiré automatiquement après une période d'inactivité. Le GUID de la session de connexion sera "mémorisé" par l'application Web pour chaque utilisateur connecté (soit stocké dans le billet d'authentification des formulaires, soit en session).
Le service WCF fournira également à sa propre opération de connexion acceptant un nom d'utilisateur et un mot de passe et renvoyer un guid de session de connexion comme décrit ci-dessus.
Le service WCF accepterait alors le GUID de la session de connexion pour toutes les autres opérations et vérifie que le GUID représente une session de connexion valide qui n'a pas expiré avant de permettre à l'opération de procéder.
J'ai fait un peu de lecture de fond à ce sujet, et il y a beaucoup de matériel sur l'utilisation directe du type d'identification du client Nom d'utilisateur, mais cela nécessiterait que l'application Web se souvienne du mot de passe de l'utilisateur, qui ne semble pas comme une bonne idée pour moi.
J'ai fait des recherches et j'ai trouvé du matériel sur MSDN, mais cela ressemble à beaucoup d'efforts pour mettre en œuvre ce qui (pour moi au moins) semble être un scénario d'utilisation assez courant.
Comment: créer un Jeton personnalisé
est l'approche générale de la "session de connexion" décrite ci-dessus raisonnable?
Si oui, quelle est la meilleure façon de le réaliser?
Sinon, pouvez-vous suggérer une alternative?
6 Réponses :
Il y a deux solutions possibles que je peux penser:
Premièrement, si le service WCF est un service interne, l'application Web peut ensuite envoyer le nom de l'utilisateur qui demande les données avec chaque demande.
La seconde est que vous stockez le nom d'utilisateur et le hachage du mot de passe (ou du mot de passe réel) quelque part. Soit dans l'état de la session ou dans le cookie de l'utilisateur (un cookie de session stocké dans la mémoire transmis à l'utilisateur via HTTPS). Puis transmettez le nom d'utilisateur et le mot de passe sur le service WCF avec chaque demande.
Le service WCF sera disponible sur Internet. Si je stocke un hachage du mot de passe, j'ai besoin d'activer l'authentification avec le service de WCF à l'aide du hachage du mot de passe - autant que je puisse le voir, cela ne le rend efficace que d'un mot de passe (bien qu'il serait difficile / impossible de deviner ), mais toujours quelque chose qui serait "de manière permanente" utile s'il est compromis (au moins jusqu'à ce que l'utilisateur a changé de mot de passe). L'utilisation de l'approche de jeton de session de connexion que j'ai initialement décrite signifie que le jeton de la session de connexion n'était valable que pour une courte période et serait beaucoup moins risqué s'il est compromis.
Voir ma réponse sur Stockage de mot de passe dans les formulaires Authentification Cookie - ASP.NET et WCF Appels pour une solution qui ne nécessite pas de stockage de mots de passe.
J'avais lu la réponse que vous référence avant de poster cette question. Cela ressemble à une approche intéressante, mais je suis un peu floue sur la mécanique. Pourriez-vous clarifier ou donner un exemple?
@Secret Squirrel, j'ai développé la réponse dans l'autre page.
C'est une approche très raisonnable.
Pour ce faire, vous configurez votre point d'extrémité de service et configurez-le avec votre fournisseur de membre personnalisé (vous pouvez faire la même chose avec le fournisseur d'adhésion SQL, il ne nécessite pas de personnalisé).
sur le web Application Vous configurez l'événement authentifié du contrôle de connexion pour instancier un nouveau proxy de service et définir le nom d'utilisateur / mot de passe dans les crosscréentiels dans le proxy.
Maintenant, lorsque vous faites appel au service via le proxy WCF passera ces informations d'identification via le canal sécurisé au service et les utilisera pour l'authentification.
Vous devez simplement stocker le proxy en session et l'utiliser pour un accès futur au service, car il a l'état de la chaîne et une clé privée.
Je pense que votre suggestion est intéressante, mais je suis préoccupé par ce qui se passerait si le canal défaut (erreur de communication, exception de service non gérée, etc.) - La session d'application Web contiendrait une référence à un proxy mort et il n'y aurait aucun moyen de créer Un nouveau proxy depuis que je n'aurais pas accès au mot de passe de l'utilisateur.
Après avoir réfléchi à votre suggestion, je ne pense pas que ce type d'approche serait approprié. L'application Web doit interagir avec plusieurs services WCF (avec les mêmes informations d'identification de l'utilisateur) et cette approche vous obligerait à créer un proxy pour chaque service au point lorsque l'utilisateur se connecte et cache toutes ces références de proxy dans la session. Je ne pense pas que cela va bien augmenter et je dois prendre en charge un grand nombre d'utilisateurs simultanés sur un serveur partagé.
Chaque fois que vous instanciez le proxy, il doit passer par une poignée de main pour établir un canal sécurisé. Selon la configuration, cela peut inclure un échange de certificat et générer et partager une clé de cryptage éphémère. La mise en cache Le proxy élimine cet échange de se produire sur chaque demande. Je ne sais pas comment répondre à la question sur la chaîne fauchée car je n'ai pas testé ce scénario. S'il ne rétablit pas automatiquement, vous auriez probablement besoin de sauvegarder le nom d'utilisateur / mot de passe quelque part également. Je ne sais pas que vous auriez une grande partie de choix.
Je suggérerais de jeter un coup d'œil à Genève qui est visant à résoudre des scénarios comme le vôtre. L'idée de base est d'exiger le même jeton de sécurité, par la moyenne d'un httpmodule, pour les services de la WCF et le site ASP. Le jeton sera libéré après l'authentification contre votre base de données d'adhésion et peut contenir des informations utiles (réclamations) sur l'utilisateur.
Pour une intro, vous pouvez lire Article de Bustamante .
J'avais regardé à Genève à la suite de la lecture de l'article de Bustamente il y a quelques mois, et cela ressemble à une solution possible, mais c'est toujours en version bêta et j'ai malheureusement besoin d'une solution maintenant. :-)
Merci à tous pour votre contribution. Je me suis installé sur une approche (au moins pour l'instant). C'est assez simple et fonctionne bien pour mes besoins.
Utilisation du "nom d'utilisateur" clientCredentialType et une méthode de connexion de service explicite qui renvoie un jeton de sécurité (Détails de la génération de jeton omis pour la brièveté), le client de service peut décider de transmettre le mot de passe authentique en tant que propriété de mot de passe sur les informations d'identification du client ou. le jeton de sécurité à la place (obtenu à partir de la méthode de connexion). Si le client est une application Web, le jeton de sécurité pourrait être stocké dans le ticket d'authentification des formulaires, ou la session, ou où.
Utilisation de la "personnalisation" USERNAMPassWordValidationMode et une implémentation personnalisée de USERNAMPasswordValidator, le validateur inspecte le mot de passe pour déterminer s'il s'agit d'un jeton de sécurité valide ou d'un mot de passe - s'il s'agit d'un mot de passe, les informations d'identification du client sont authentifiés par l'utilisateur (SQL Server Base de données), et si c'est un jeton de sécurité, il est vérifié pour vous assurer qu'il est valide, n'a pas expiré et appartient au nom d'utilisateur.
Microsoft dispose d'un service WCF que vous pouvez utiliser pour authentifier les utilisateurs avec l'adhésion ASP.NET.
Le code est en fait intégré dans le cadre - il vous suffit de créer un fichier .SVC pour l'utiliser.
Votre service WCF est-il accessible uniquement à partir du réseau interne? Si tel est le cas, je ne vois pas la nécessité de rééditer des demandes.
Désolé pour l'omission - le service WCF sera disponible sur Internet.