authentification dans une architecture multicouche

Question

Je suis la conception d'un système N-couche dans .NET qui consistera

• SQL Server 2008
• EF 4
• dépôt de couche
• Service Layer (Business Logic)

en plus de cela je devrai:

• site ASP.NET MVC
• API externe à consommer par d'autres clients (construits avec WCF ou ServceStack.NET)

Je voudrais mettre en œuvre le nom d'utilisateur typique/mot de passe auth dans l'application MVC comme ainsi que les options de connexion OpenID/twitter/facebook

L'API nécessitera des formes d'authentification similaires.

Où dans l'architecture est le meilleur endroit pour mettre en œuvre l'authentification et sont des échantillons disponibles de la façon de mettre en œuvre quelque chose comme ça avec une pile .NET?

Un fournisseur d'abonnement personnalisé est-il une option pour cela?

Je me rends compte qu'il ya des bibliothèques disponibles pour mettre en œuvre la partie openID de sorte que n'est pas une préoccupation pour le moment mais je voudrais laisser les choses ouvertes à ajouter à l'avenir.

Suggestions?

Answer 1

L'authentification doit être effectuée au point de contact avec l'utilisateur: site Web MVC et service WCF.

Dans chaque point, utilisez le mécanisme d'authentification/autorisation approprié.

site MVC: l'authentification des formulaires (ou l'authentification Windows, etc.)

service WCF: (quelle méthode vous prenez, clé API, utilisateur/mot de passe de nom sur chaque demande, clé sécurisée, auth biscuits, etc.)

Pour chaque point, appelez la couche de service avec les informations d'identification utilisées par le demandeur (utilisateur) et valider contre votre base de données (dans la couche de service).

La couche de service doit renvoyer valide/non valide pour les informations d'identification qui lui sont attribuées.

S'il s'agit de non valide, demandez à votre site Web ou service Web de rejeter toute autre action de la part de l'utilisateur et de l'informer que celle-ci n'est pas valide.

Si elle est valide , ont votre site Web MVC créer le cookie auth (FormsAuthentication.SetAuthCookie) et votre service WCF faire l'action appropriée pour le mécanisme d'authentification choisi.

Gardez votre couche de service indépendante de l'authentification. Il ne doit répondre que si un ensemble d'informations d'identification est valide et que vos couches frontales doivent prendre soin de définir les tickets d'authentification.

Pour les identifiants Open ID/Twitter/Facebook, toutes les informations nécessaires sont sur l'application web (via les cookies de la source de connexion), utilisez-les pour configurer le cookie d'authentification de votre site Web.

Answer 2

Une architecture de base serait d'utiliser les membres asp.net api pour vos applications de services web et dans la même appelant la base de données des membres. Ensuite, utilisez un utilisateur avec emprunt d'identité pour vous connecter à SQL Server.

Vous pouvez ensuite écrire des fournisseurs d'appartenances personnalisés pour les autres mécanismes d'authentification ou les incorporer tous dans un fournisseur d'appartenances.

Answer 3

Désolé a dû écrire cela comme une autre réponse car n'avait pas assez d'espace dans les commentaires.

Configurez le fournisseur d'appartenances au niveau IIS et utilisez le fournisseur d'appartenances SQL OOTB pour que l'authentification de base fonctionne. Vous pouvez ensuite écrire un membre personnalisé que la couche du référentiel exécutera dans le contexte de l'application Web, soit sur le service web, soit sur le site asp.net, afin que vos informations d'authentification se trouvent dans le httpcontext, vous pouvez ensuite utiliser à votre base de données ou utilisez un compte usurpé, c'est-à-dire l'utilisateur du pool d'applications pour se connecter à la place.

Vous pouvez ensuite écrire un fournisseur d'appartenances personnalisé qui s'authentifie auprès des autres fournisseurs si vous le souhaitez, et remplacez le standard SQL par un fournisseur personnalisé.

Answer 4

En complément Omar's answer:

Vous pouvez également utiliser un Facade Pattern qui gère l'autorisation et est utilisé par le WCF et le code MVC et fournit l'API à la couche d'affaires. Une règle de base est la suivante: Mettez l'autorisation en un seul point et laissez l'authentification automatique être traitée par le (s) client (s). Ne le répandez pas sur votre couche de service!