Service d'interface utilisateur ~ Authentification du service principal

Question

Je suis en train de concevoir (oui à peu près toujours en concevant) une architecture dans laquelle nous avons un service principal qui fait des choses. Authentifie les utilisateurs, importe les données et obtient des résultats, etc. Nous avons également un module ASP MVC3 UI qui interagit avec lui. La clé ici est qu'à l'avenir, il pourrait s'agir de SharePoint ou simplement d'une application d'importation en vrac utilisant le service, donc il faut être conscient, mais pour l'instant c'est un ASP MVC3.

Ce que j'ai du mal à décider/à comprendre est l'authentification. J'aime MembershipProvider plus sur J'aime SqlProvider. Nous sommes une maison M $ donc je suis heureux de descendre cette route. Ce que je veux faire est de lier l'authentification de l'utilisateur se connectant à l'interface utilisateur avec l'authentification sur les appels de service réels. En gros, il y a 2 types d'utilisateur 'normal' et 'admin' et je ne peux pas décider de la façon la plus élégante de gérer l'authentification.

J'aime vraiment ce que j'ai. SqlProvider offert par le service WCF et l'accès sur les appels de service sont tous liés à cela (je dois ranger cela car tous les appels de service sont actuellement verrouillés par config plutôt que par contrat de service). Le problème avec ceci est que vous devez passer le nom d'utilisateur et le mot de passe sur le texte clair et pour éviter que vous soyez dans le monde des certificats - Ma recherche indique ici que les certificats de dev sont mauvais et réels sont une option. La question est la suivante: quelle est la meilleure approche? Je veux Un service qui i) Authentifie sur chaque appel de sorte que vous ne pouvez pas appeler quelque chose que vous n'autorisez pas - manipulé aussi élégamment que possible ii) Est apatride afin que je puisse escalader/grouper le service. iii) n'est pas un contrôle côté client, donc il peut être remplacé. L'alternative aux certificats J'ai pensé à ce qu'un appel de connexion au service qui renvoie un jeton quelconque est ensuite transmis avec les autres appels et authentifié en utilisant un fournisseur principal personnalisé. Les avantages à cela sont que je peux utiliser des cryptage Windows entre l'interface utilisateur et le service et transmettre l'authentification pour les rôles à côté. Ce que je veux éviter de faire est de passer des détails dans les paramètres de chaque appel car cela semble moche.

Aidez s'il vous plaît!

Answer 1

WCF offre la possibilité d'ajouter des champs personnalisés à l'en-tête SOAP, ce qui permet d'extraire les problèmes transversaux comme l'authentification des paramètres de message & traités à un niveau légèrement supérieur.

Mais ce n'est pas tout. WCF vous permet également de crypter ces en-têtes, ce qui les empêchera d'être envoyés sur le fil en texte brut. This blog post par Steven Cheng fournit une bonne description de la façon d'accomplir cela. Essentiellement, vous allez créer un comportement de contrat personnalisé qui peut être facilement appliqué à vos services existants.