Comment autoriser plusieurs méthodes d'authentification dans ASP.NET?

Question

Je construis une nouvelle application ASP.NET MVC (en C#) et l'une des exigences est de créer une nouvelle base de données de membres. Pour cela, nous aurions besoin de rôles pour gérer les différents types de membres et de profils pour gérer les métadonnées supplémentaires attachées à chaque membre. Jusqu'ici tout va bien, il suffit d'utiliser le MembershipProvider standard, RoleProvider et ProfileProvider fournis dans le cadre du .NET Framework.

Cependant, le problème est que je voudrais autoriser différentes méthodes d'authentification. Je souhaite que les comptes et les informations d'identification de connexion aient une relation un-à-plusieurs (un compte peut avoir un certain nombre d'informations d'identification de connexion). Un utilisateur, par exemple, peut avoir un compte OpenID et ActiveDirectory associé à son compte. Cependant, après quelques expériences, nous avons opté pour l'itinéraire MembershipProvider (expliqué comment cela a été réalisé comme une réponse ci-dessous).

Ma question est la suivante: comment les gens ont-ils déjà fait cela et comment les gens me suggèrent-ils de l'approcher? Il semble être quelque chose qui est réalisé sur un certain nombre de sites, mais une recherche sur ce site ne retourne rien de solide à jouer avec.

EDIT: Après avoir regardé autour pendant une bonne période d'heures du jour au lendemain et ce matin - je ne suis toujours pas convaincu que l'abattage d'un seul MembershipProvider aurait été l'option la plus facile. Avoir plusieurs MembershipProviders donne-t-il le même effet?

BOUNTY EDIT: Sans réponse, je suppose qu'il n'y a pas de solution plus optimale que celle que j'ai affichée comme réponse. Est-ce vraiment le cas? J'offre une prime pour essayer de voir si quelqu'un a d'autres idées à ce sujet et s'il y a de meilleures alternatives.

BOUNTY ACCEPT EDIT: Je pense que WIF est la réponse acceptée ci-dessous, pour une version .NET 4 et peut-être d'autres versions car elle fonctionne probablement avec 3.5. Autre que cela, peut-être un MembershipFovider bouché ou adapté peut encore être pertinent.

Answer 1

À mon avis, la « vraie façon » de faire est d'utiliser la fédération avec WIF (Windows Identity Foundation, anciennement le cadre de Genève).

L'idée est que vous vous séparez authentification de autorisation. L'authentification est effectuée par un soi-disant STS (Security Token Service) et il gère tous les mécanismes de connexion possibles que vous voulez prendre en charge. Lorsqu'un utilisateur a été authentifié, le STS émet un jeton contenant un ensemble de revendications et l'identité de l'utilisateur. Ce jeton est envoyé au site Web (appelé une partie de confiance dans ce jargon), et le site Web détermine les parties du site auxquelles l'utilisateur a accès en fonction des revendications dans le jeton. WIF fournit à la fois des membres et des fournisseurs de rôles qui extraient des informations de jeton.

Vous pouvez en savoir plus sur la création d'un claims aware website here.

L'un des avantages de cette approche est la séparation des préoccupations entre l'authentification et l'autorisation. Vous n'avez pas besoin de membres et de fournisseurs de rôles complexes sur votre site Web. De plus, le STS peut être réutilisé pour authentifier les utilisateurs à d'autres applications que vous pourriez avoir sans avoir à s'enregistrer plus d'une fois (réalisant ainsi l'authentification unique).

L'inconvénient est que vous devrez passer du temps à étudier ces concepts et coder votre STS. Rappelez-vous, il n'est pas difficile de coder un STS avec WIF, mais ce n'est pas une tâche 100% triviale non plus.

Si j'ai réussi à susciter votre intérêt, je vous recommande de commencer par lire this whitepaper.

Cordialement,

Klaus

Answer 2

Une idée que nous avons suivie est de créer un fournisseur de membre/rôle/profil personnalisé. Nous avons personnalisé les méthodes de connexion/authentification de manière significative et avons un tableau supplémentaire des connexions. Ce tableau fondamentalement juste contenu:

LoginID (Auto-Incremental ID, PK) 
UserID (FK) 
LoginSystemID (FK) 
...blah blah 

Dans ce qui précède, le LoginSystemID était un lien vers une table de recherche étrangère qui a permis au système de déterminer quel service d'authentification à utiliser (par exemple standard, AD, OpenID, FacebookConnect - etc) . Le problème que nous avons rencontré était que le champ Nom d'utilisateur dans MembershipProvider ne pouvait pas être vide et alors que dans notre schéma tout le monde avait un UserID (c'était leur nom de compte), ils n'avaient pas de nom d'utilisateur qui était unique. Nous avons dû contourner cela en générant un GUID et en l'utilisant. Ceci est bien sûr caché à l'utilisateur et un attribut DisplayName de notre table Users peut être affiché à la place.

Tout cela a été effectué via FormsAuthenication (les vérifications AD ont été effectuées via des vérifications LDAP). Cependant, une couche supplémentaire (un formulaire Web) a été ajoutée avec des paramètres appropriés dans IIS qui fournissaient un moyen d'authentification automatique Windows - nous redirigeons vers l'instance dans laquelle nous pensons que l'utilisateur est susceptible d'être interne (basé sur l'adresse IP).

Answer 3

Utilisez un cadre standard.Voir http://blogs.teamb.com/craigstuntz/2009/09/09/38390/

Vous pouvez avoir un nombre illimité de méthodes d'authentification jointe à un compte, la magie est dans la déclaration FormsAuthentication.SetAuthCookie(userName, createPersistentCookie);