Envisager de scrapper mon idée d'écrire un membre personnalisé et un fournisseur de rôles. Des avis?

Question

J'ai une application web Je construis dans ASP.NET qui a les exigences de sécurité suivantes:

1. doit être en mesure d'intégrer un système d'authentification maître qui passe en arrière une clé unique à l'application de indiquer qu'un utilisateur s'est connecté via un site tiers.
2. Doit pouvoir utiliser les tables utilisateur/rôles existantes.
3. Peut utiliser l'authentification par formulaire et autoriser les utilisateurs à se connecter via une page de connexion distincte s'ils ne sont pas membres du site tiers.

J'ai essayé de personnaliser les fournisseurs de rôle SQL et l'adhésion, mais je rencontrer des problèmes, en particulier qu'il ya un objet MembershipUser fortement typé qui a une uniqueIdentifier (ProviderKey) et ne dispose pas de place pour ma propre ensemble de clés personnalisées (il y en aura deux) qui identifient les utilisateurs. Dois-je abandonner l'implémentation de mon fournisseur d'appartenances personnalisées et utiliser plutôt les cookies/sessions? J'aimerais vraiment utiliser la fonctionnalité intégrée, mais cela ne semble pas faisable.

Answer 1

Ce que vous pourriez vouloir faire est de construire votre article 1 au-dessus de la fonctionnalité existante, essayez ceci en premier. Avec les informations retournées, connectez-vous automatiquement l'utilisateur po Si le premier processus échoue, faites l'authentification standard en utilisant le code intégré.

J'ai construit ce type de système sur le fournisseur d'adhésion ASP.NET plusieurs fois pour les clients utilisant DotNetNuke, cela fonctionne très bien.

Answer 2

Allez-y, here's the source to the built in ASP.NET 2.0 Membership provider sur le blog de Scott Guthrie.

Answer 3

J'ai réussi à abandonner le fournisseur d'appartenances et à ne pas l'utiliser du tout. J'ai créé une nouvelle interface IMembershipService et une implémentation pour celle qui gère la création et la vérification des utilisateurs de mon application web.

J'ai créé mon propre modèle utilisateur. Cela me permet d'avoir un modèle de rôle flexible dans mon application. Je suis libre de créer des rôles de domaine contextuels et de les découpler du modèle utilisateur réel.

Ce n'est vraiment pas si difficile. N'oubliez pas de sel vos mots de passe etc. et lisez quelques livres de sécurité.

Vous pouvez toujours utiliser FormsAuthentication avec cette approche.

La plupart des systèmes qui dépendent du fournisseur d'appartenance asp.net sont vraiment schizophrènes. Vous aurez 2 tables Utilisateurs, par exemple dans CommunityServer vous avez aspnet_users et cs_Users où cs_Users fait référence à MembershipId de aspnet_users et où il introduit encore un autre UserId. Il reflète également le nom d'utilisateur, etc.