. NET Mitgliedschaft in nTier App

Question

Sagen wir, ich habe eine ASP.Net MVC App und diese App (UI) verweist auf eine Business Logic Layer (BLL) und die BLL verweist auf meine Data Access Layer (DAL).

Ich verwende einen benutzerdefinierten Mitgliedschafts- und Rollenanbieter für die Autorisierung.

Ich versuche zu bestimmen, welche Schichten auf meinen Mitgliedschaftsanbieter verweisen müssen.

In MVC Sie Berechtigungsprüfungen in der folgenden Art und Weise durchführen können:

[Authorize(Roles = "SomeRoleName")] 
public ActionResult Index() 
{ 
//do something 
} 

Und in meinem BLL kann ich mag überprüfen, um zu sehen, ob ein Benutzer in einer Rolle als auch ist:

public static bool IsRoleEditor(User user, Role userRole) 
    { 
    bool retValue = false; 

    if (user.Application.AppID == UserRole.Application.AppID) 
    { 
     if (Roles.IsUserInRole("ModifyRoles")) 
     { 
      retValue = true; 
     } 


    return retValue; 
    } 

Ich müsste die Mitgliedschaft Klassen in beiden Schichten verweisen und instanziieren, wenn ich dies tue. Ist das der richtige Weg, um eine App so zu erstellen? Scheint wie eine Menge Redundanz.

Da ich eine BLL habe vermeide ich die Verwendung der "[Authorize (Roles =" SomeRoleName ")]" Attribute und rufen Sie stattdessen eine BLL-Funktion aus dem MVC-Code, um zu überprüfen, ob der Benutzer in einer Rolle ist? Wenn ich das tue, benötigt der MVC immer noch einen Verweis auf den Mitgliedschaftsanbieter für die Authentifizierung und so, um die Login- und andere ASP-Steuerelemente trotzdem zu nutzen, richtig?

Bin ich weg von der Basis und in die falsche Richtung?

Answer 1

Meiner Ansicht nach ist dies eine Schwäche der Mitgliedschaft/Rollendesign. Die Art, wie ich dies umgehen würde, um beispielsweise eine rollenbasierte Autorisierung sowohl auf UI- als auch auf BLL-Ebenen in einer verteilten n-Tier-App zu haben, wäre, einen Dienst in der BLL-Ebene verfügbar zu machen, der die relevanten Bits freigibt (GetRolesForUser usw.) und wird implementiert, indem der RoleProvider auf dem Server aufgerufen wird.

Implementieren Sie dann einen benutzerdefinierten RoleProvider auf dem Client, der durch Aufrufen des von der BLL bereitgestellten Service implementiert wird.

Auf diese Weise teilen sich die UI-Ebene und die BLL-Ebene den gleichen RoleProvider. Die UI-Schicht kann die Kenntnis der aktuellen Benutzerrollen verwenden, um die UI zu verbessern (z. B. das Ausblenden/Deaktivieren von UI-Steuerelementen für nicht autorisierte Merkmale), und die BLL kann sicherstellen, dass Benutzer Geschäftslogik, für die sie nicht autorisiert sind, nicht ausführen können.

Answer 2

Holen Sie sich Ihr Benutzerobjekt, um die IPrincipal-Schnittstelle zu implementieren und diese um die Ebenen zu werfen. Dann können Sie immer noch das eingebaute [Autorize] -Attribut verwenden.

Obwohl geschrieben vor über 3 Jahren und über Burg, kann this article helfen. Es beginnt auf halbem Weg in das IPrincipal-Zeug zu kommen.

HTHS
Charles

Answer 3

Ausgezeichnete Frage, fragte ich mich, die heute Gleiche. Eine der Ideen, die ich hatte (aber ich bin mir nicht sicher, ob es der beste Weg ist), ist die Verwendung einer Schnittstelle (zB IRoleProvider), die Sie an Ihren BLL übergeben können, um Ihren Zugriff zu testen.

public static bool IsRoleEditor(User user, IRoleProvider rp) 
{ 
    return (rp.IsUserInRole(user,"ModifyRoles")); 
} 

Damit Sie noch Ihren Zugang in Ihrem BLL überprüfen Sie einen Mock in Ihren Unit-Tests können Sie Ihre Logik überprüfen und Sie müssen nur eine Klasse (oder implementieren diese in einer Base Klasse) zu schaffen, in Ihre MVC-Website, die IRoleProvider implementiert und die ordnungsgemäße Prüfung mithilfe der ASP.NET-Autorisierungs-API durchführt.

Hoffe, das wird helfen.

Answer 4

Der Rollenzugriff sollte normalerweise nicht im BLL sein. Der Zugriff ist eine Verantwortlichkeit für die Benutzerschnittstelle.

Mit diesem gesagt, Hebel die IPrinciple Schnittstelle wie die oben genannten Plakate angegeben haben. Sie haben Zugriff auf IPrinciple auf der Thread-Ebene.

Thread.CurrentPrincipal 

Answer 5

Warum nicht die Rollen in Ihre BLL übergeben, so dass Sie keine Abhängigkeit von der Mitgliedschaft haben. Oder verwenden Sie eine Schnittstelle wie MartinB vorgeschlagen.

Was passiert in der Zukunft, wenn sich Ihr (e) Interessenvertreter (n) für eine andere Form der Authentifizierung entscheiden und Sie nicht mehr mit einem Role Objekt arbeiten?

Beispiel:

IsRoleEditor(User user, string[] roles) 
{ 
    return roles.Contains("ModifyRoles"); 
} 

Answer 6

Verpassen Sie nicht den Punkt von MVC. MVC spaltet sich natürlich in Tiers auf. Modell (DAL), Controller (BLL), Ansicht (Präsentation). Diese können in verschiedenen Projekten verwendet werden, wenn Sie möchten, aber da der Controller über die gesamte Geschäftslogik verfügt, müssen Sie nur auf den RoleProvider zugreifen.

Dann wenden Sie Muster wie das Repository, Muster usw. an, um weiter zu teilen, wenn Sie wollen.

Davy

Answer 7

Um die MVC-Controller ‚UI‘ zu nennen, ist Art und Weise weg von der Markierung .. Das ‚C‘ in MVC Teil Ihrer BLL ist, auch wenn es Klassen verweist, die Sie das nennen würde BLL. Das ist jedoch nicht der Punkt Ihrer Frage.

Ich denke, ich würde dieses Problem lösen, indem ich die Frage stelle: "Gibt es eine echte Anforderung für die 100% ige Trennung Ihrer 'UI' App und Ihres 'BLL'?". Wenn beide Komponenten eine Abhängigkeit von den Member/Role-Providern haben, dann lass es so sein und mach weiter.

In dem Fall, in dem Sie Ihre BLL trennen und eine neue einstecken, können Sie möglicherweise mit einer gemeinsamen Abhängigkeit von einem .NET-Anbieter leben. Du weißt, dass das wahrscheinlich in Ordnung ist und deine App nicht auseinander fallen könnte. obwohl ...

Answer 8

denke ich Joes Antwort oben viel Sinn macht, ich glaube, was Sie tun, ist in Ordnung.

Die Autorisierung und Authentifizierung sollte innerhalb einer Services-Schicht stattfinden, die möglicherweise an Ihre Controller weitergegeben wird.

Wenn der Controller den Principal und die Identität festlegt und Sie diesen dann über die MVC-Attribute im Controller verwenden, dann klingt das nach einer guten Idee.

Es wäre nett, Ihren MVC-Mitgliedschaftsanbieter hinter einer Schnittstelle zu verbergen, so dass Sie ihn zum Beispiel für einen WinForms-Mitgliedschaftsanbieter austauschen und Ihre Controller testen könnten.