Ich habe einen Business-Logik-Layer (das "Repository"), der als eine Reihe von .NET-Schnittstellen verfügbar gemacht wird, die durch auslagerbare konkrete Implementierungen unterstützt werden.Sollte die Business-Logik-Ebene Autorisierung und Authentifizierung implementieren?
Ursprünglich hatte ich diese Business-Schicht implementieren Authentifizierung und Authenz (authn/authz), dh ich hatte Schnittstellen wie IUserIdentity und IUserRole, und alle Methoden, die auf sensible Daten zugegriffen, nahm eine IUserIdentity und führte Autorisierung vor dem Erlauben der Aktion.
Die Business-Schicht war bis jetzt sehr front-end-agnostisch ... aber jetzt, wenn ich versuche, in eine ASP.NET-Website zu integrieren, erkannte ich, dass ASP.NET selbst eine reiche Authentifizierung/Autorisierung hat System über die Mitgliedschafts- und Rollen-APIs integriert.
Die Frage ist also, sollte ich alle Authn/Authz aus der Business-Logik-Ebene entfernen und auf das Web-Frontend verlassen, um dies zu tun? Das würde die Dinge viel vereinfachen, aber ich weiß nicht, ob ich es später bereuen werde, es herauszuziehen.
Die Alternative ist, die Authn/Authz in meiner Geschäftslogik zu halten, aber integrieren Sie es mit ASP.NET über benutzerdefinierte Mitgliedschaft/Rolle Anbieter. Aber das scheint wirklich beschwerlich zu sein ... Ich muss immer noch die Kosten dafür untersuchen.
Was würden Sie tun (oder getan haben) und warum?
Eigentlich (Entschuldigung, ich hätte das erwähnen sollen) Ich verwende ASP.NET MVC, die das Aspektkonzept für die Sicherheit über das Autorize-Attribut implementiert. – DSO
Attribute in .NET sind wie Anmerkungen in Java EE, wenn ich mich richtig erinnere. Gibt es etwas wie die Ausdruckssprache von AspectJ, um einen Aspekt auf eine Reihe von Methoden, Klassen und Paketen anzuwenden? – duffymo