Services WCF: passage d'un jeton pour valider un abonnement et obtenir des informations sur la base de données

Question

Je crée une application client intelligente à l'aide de .NET 3.5. Un client Winforms connexion par le biais des services WCF pour récupérer des données à partir de SQL Server 2008. Je dois passer un nom d'utilisateur/mot de passe (crypté et HTTPS) et de renseignements tels que:

• Est-ce l'utilisateur (adresse e-mail) sous un abonnement en cours
• Quel serveur devons-nous passer à la prochaine pour tous les appels suivants (équilibrage de charge de pauvre)
• Quel serveur/base de données doit être utilisé dans la chaîne de connexion (informations d'identification non requises), car les utilisateurs peuvent utiliser différents bases de données en fonction de leur abonnement, etc.

Donc, mon premier appel lors de la signature envoie les informations d'identification qu'une recherche est effectuée. Une classe sérialisable sera utilisée pour créer un objet symbolique (je suppose que c'est la façon de gérer cela) qui renverra l'expiration, les informations du serveur, les informations de la base de données. La question est sur tous les appels suivants dois-je passer ce jeton en tant que paramètre à chaque contrat de service (méthode web) ou puis-je laisser tous mes contrats actuels tels quels et passer le jeton dans un en-tête ou une autre méthode plus universelle ?

Comment proposez-vous la mise en place d'un système de jetons tel que je le décris?

Merci

Answer 1

D'une part, je ne retourne un TokenID - une pièce d'identité unique pour identifier clairement l'utilisateur et son abonnement en question - de votre premier appel « d'authentification ». Il n'est pas nécessaire de renvoyer l'ensemble des informations en permanence - seul le service côté serveur a besoin de ces informations, vous pouvez donc laisser ces informations sur le serveur et ne les consulter dans votre code serveur qu'en cas de besoin. Alors le premier appel - l'appel d'authentification - vérifierait probablement les informations d'identification envoyées sur une table de base de données, par rapport à une table d'abonnement, puis placerait ces informations (qui appelle, en fonction de quel abonnement) et éventuellement d'une date/heure d'expiration dans une table "Callers valides" et générer un identifiant à partir de celui-ci (un GUID ou quelque chose). Vous pourriez vouloir limiter la "durée de vie" d'un TokenID - par ex. il est valide pendant 30 minutes ou plus - de sorte qu'il ne peut pas être détourné et utilisé perpétuellement après un premier appel réussi. Ce GUID généré est renvoyé comme TokenID à partir de l'appel d'authentification et peut être utilisé comme identificateur lors de chaque appel suivant. Des choses comme le serveur de base de données à utiliser n'ont vraiment aucune place dans les messages qui vont et viennent - ils sont strictement importants pour le code de service côté serveur - il suffit de les laisser là!

Il est certainement préférable de mettre ces "méta-informations" qui ne sont pas les informations de valeur réelle pour vos appels dans les en-têtes et d'y chercher. WCF prend en charge cela très bien et facilement - avec les inspecteurs de message (sample for that here et here) sur le client et le côté service, ou en utilisant le OperationContextScope (exemple blog post here et here) - les deux fonctionnent très bien.