Ich denke darüber nach, meine Idee, einen benutzerdefinierten Anbieter für Mitgliedschaft und Rollen zu schreiben, aufzugeben. Meinungen?

Question

Ich habe eine Webanwendung, die ich in ASP.NET entwickle und die die folgenden Sicherheitsanforderungen hat:

1. Muss mit einem Master-Authentifizierungsschema integriert werden können, das einen eindeutigen Schlüssel an die Anwendung zurückgibt, um anzuzeigen, dass sich ein Benutzer über eine Drittanbieter-Website angemeldet hat.
2. Sie müssen in der Lage sein, bestehende Benutzer-/Rollentabellen zu verwenden.
3. Sie können eine Formularauthentifizierung verwenden und es den Nutzern ermöglichen, sich über eine separate Anmeldeseite anzumelden, wenn sie nicht Mitglied der Website des Drittanbieters sind.

Ich habe versucht, die SQL-Rollen- und Mitgliedschaftsanbieter anzupassen, aber ich stoße auf Probleme, insbesondere, dass es ein stark typisiertes MembershipUser-Objekt gibt, das einen eindeutigen Bezeichner (providerKey) hat und keinen Platz für meinen eigenen benutzerdefinierten Satz von Schlüsseln hat (es wird zwei geben), die Benutzer identifizieren.

Sollte ich meine benutzerdefinierte Mitgliedschaftsanbieter-Implementierung aufgeben und stattdessen einfach Cookies/Session verwenden? Ich würde wirklich gerne die integrierte Funktionalität verwenden, aber es scheint nicht machbar.

Answer 1

Vielleicht möchten Sie Ihr Element 1 über die bestehende Funktionalität hinaus aufbauen, versuchen Sie das zuerst. Mit den zurückgegebenen Informationen melden Sie den Benutzer automatisch an. Wenn der erste Prozess fehlschlägt, führen Sie die Standardauthentifizierung mit dem eingebauten Code durch.

Ich habe diese Art von System auf der Grundlage des ASP.NET-Mitgliedschaftsanbieters viele Male für Kunden mit DotNetNuke gebaut, es funktioniert sehr gut.

Answer 2

Los geht's, Hier ist der Quellcode des eingebauten ASP.NET 2.0 Membership Providers aus dem Blog von Scott Guthrie.

Answer 3

Ich habe mich erfolgreich von dem Mitgliedschaftsanbieter getrennt und benutze ihn überhaupt nicht mehr. Ich habe eine neue IMembershipService-Schnittstelle und eine Implementierung dafür erstellt, die die Erstellung und Überprüfung der Benutzer meiner Webanwendung übernimmt.

Ich habe mein eigenes Benutzermodell erstellt. Dies ermöglicht mir, ein flexibles Rollenmodell innerhalb meiner Anwendung zu haben. Ich kann kontextbezogene Domänenrollen erstellen und sie vom eigentlichen Benutzermodell entkoppeln.

Es ist wirklich nicht so schwer. Denken Sie daran, Ihre Passwörter zu salzen und lesen Sie ein paar Sicherheitsbücher.

Sie können FormsAuthentication auch mit diesem Ansatz verwenden.

Die meisten Systeme, die sich auf den asp.net membership provider verlassen, sind in gewisser Weise schizophren. Sie haben 2 Benutzertabellen, zum Beispiel in CommunityServer haben Sie aspnet_users und cs_Users, wobei cs_Users auf die MembershipId von aspnet_users verweist und eine weitere UserId einführt. Sie spiegelt auch den Benutzernamen usw.