Rollenanbieter/Mitgliedschaft? Wie in asp.net Web API?

Question

Ich baue eine asp.net mvc Web-API-Anwendung und nicht sicher, wie man die Mitgliedschaft Sachen zu tun.

In meinem aktuellen Projekt habe ich dieses

Meine eigene Users Table und Role Table ich nicht asp.net Mitgliedschaft verwende, da es zu viel Gepäck bringt und passt nicht, wie ich meine Datenbank entwerfen möchten (sicher ich kann es aber es scheint, wie zu viel Arbeit)

A user kann viele Rollen haben und ein roleviele Benutzer haben.

Ich verwende EF, um fast alle meine Anrufe in die Datenbank zu tun.

In früheren Projekten habe ich meine eigene Authorize Attribute gemacht, was mein eigener Aufruf zu meiner Datenbank und überprüft hat, ob der Benutzer in der richtigen Rolle war, als was auf dieser Controller/Aktionsmethode erlaubt war.

Indem ich keine Mitgliedschaftsanbieter machte, verlor ich einige der eingebauten Funktionen wie User.IsInRole. Ich konnte immer noch User.Identity.Name verwenden, aber ich denke, das war wegen dem Cookie, den ich gesetzt habe.

Was ist der beste Weg, es jetzt in asp.net mvc 4/web api zu tun?

Beim googeln habe ich "SimpleMembership" gefunden, habe aber noch nicht viel gelesen.

Auf einer Seitennotiz kann ich User.Identity.Name mit meinem Webapi verwenden, wenn ich einen Benutzer authentifizierte?

Answer 1

Hier ist ein article that describes how to create a custom authorize attribute for Web API's using SimpleMembership. Sie müssen SimpleMembership nicht verwenden, obwohl es sehr flexibel und einfach zu verwenden ist. Sie könnten die gleichen Konzepte in diesem Artikel verwenden und stattdessen Ihren Mitgliedschaftsdienst verwenden, solange Ihr Dienst überprüfen kann, ob ein bestimmter Benutzer in einer Rolle ist, einen Benutzer anmelden und seine Identität bestätigen.

Wenn Ihr Dienst nicht überprüft, ob sie authentifiziert sind, können Sie User.Identity.IsAuthenticated verwenden, und Sie können User.Identity.Name verwenden, um den aktuell angemeldeten Benutzernamen abzurufen. Angenommen, Ihr Dienst stellt Thread.CurrentPrincipal korrekt ein, wenn sich ein Benutzer anmeldet. Es wird auch empfohlen, HttpContext.Current.User festzulegen. Wenn Sie SimpleMembership verwenden, müssen Sie sich natürlich keine Gedanken darüber machen.

Dieses benutzerdefinierte Autorisierungsattribut unterstützt sowohl die Formularauthentifizierung als auch die Standardauthentifizierung für den Fall, dass Sie Ihre API der Öffentlichkeit zugänglich machen. Es unterscheidet sich von einem Autorisierungsattribut, das auf einem Controller verwendet wird, darin, dass es einen HTTP-Statuscode von verboten zurückgibt, wenn die nicht autorisiert und nicht autorisiert sind, wenn sie nicht authentifiziert sind; anstatt auf eine Anmeldeseite umzuleiten.

Answer 2

Sie könnten immer noch einen benutzerdefinierten Mitgliedschaftsanbieter schreiben und nur die Methoden implementieren, die Sie verwenden möchten. Was die User.IsInRole betrifft, könnten Sie einen benutzerdefinierten Rollenanbieter schreiben, indem Sie von der Klasse RoleProvider erben und sie in Ihrer web.config registrieren.

Und wenn Sie keine dieser integrierten Funktionen verwenden möchten, dann verwenden Sie sie nicht und schreiben Sie statt User.IsInRoleMyService.IsInRole schreiben. Es ist wirklich eine Frage der persönlichen Präferenz, ob Sie Ihre benutzerdefinierten Anbieter rollen und die integrierten Funktionen verwenden oder einfach eine Service-Schicht schreiben möchten, die das für Sie erledigt. Ich denke, die Wahl hängt von vielen Faktoren ab, die Sie berücksichtigen sollten und die sich auf die Besonderheiten Ihres Projekts beziehen. Wenn Sie beispielsweise beabsichtigen, andere externe Entwickler an diesem Projekt zu arbeiten, ist es sinnvoller, benutzerdefinierte Mitgliedschafts- und Rollenanbieter zu wählen, da die Entwickler wahrscheinlich eher mit dieser API vertraut sind als Ihre eigenen Kenntnisse zu erlernen Serviceschicht.