Das letzte Wochenende habe ich mich mal wieder mit ASP.NET MVC beschäftigt, diesmal schon das 2. Wochenende mit der Autorisierung von Benutzern. Ich glaube, die Variante über den Enterprise Library Rules Provider ist der beste Weg.
Hier mal kurz die verschiedenen Möglichkeiten
- Enterprise Library Rules Provider - patterns & practices – Enterprise Library - Home
- eigener Controller - http://geekswithblogs.net/AzamSharp/archive/2008/02/24/119946.aspx
- Attribute - http://www.coderjournal.com/2008/03/securing-mvc-controller-actions/
- RouteHandler - http://blogs.msdn.com/mikeormond/archive/2008/06/21/asp-net-routing-and-authorization.aspx
- ActionFilter - http://blog.wekeroad.com/blog/aspnet-mvc-securing-your-controller-actions/
Also man hat sehr viele Möglichkeiten und wer sich mal durch die Links durchgeklickt hat, der wird auch mitbekommen haben, dass es sehr viele Diskussionen über den richtigen Weg gibt. Den Ausschlag für die Enterprise Library bei mir hat den Einsatz sowohl in Services, Web-Apss und WinForms mit externer Konfiguration gegeben. Man kann auch einige andere der oben aufgeführten Konzepte damit verbinden.
Aus meiner Sicht ist es schon sehr Vorteilhaft, wenn man ein Konzept einsetzt, dass über den Applikationstyp hinweg eingesetzt werden kann. Zum anderen bietet die Enterprise Library durch das Konfigurationstool eine einfache grafische Möglichkeit der Konfiguration, so dass Administratoren nicht unbedingt in die Tiefen eingeführt werden müssen. Aber bestimmt für Administratoren, die auf Sicherheit sehr viel Wert legen ist die Möglichkeit den AzMan einzusetzen. Hierbei handelt es sich um eine Konfiguration die im Active Directory abgelegt werden kann. Der Rules-Provider kann so verwendet werden, dass Geschäftsvorfälle als Regeln dienen. Es gibt noch eine Reihe weiterer netter Vorteile, also durchaus mal nachlesen.
Nun genug zu den Vorteilen, hier noch ein Verwendungsbeispiel:
1 <securityConfiguration defaultAuthorizationInstance="" defaultSecurityCacheInstance="">
2 <authorizationProviders>
3 <add type="Microsoft.Practices.EnterpriseLibrary.Security.AuthorizationRuleProvider, Microsoft.Practices.EnterpriseLibrary.Security, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
4 name="ProjectRuleProvider">
5 <rules>
8 <add expression="R:Administrators OR R:Chef"
9 name="CreateProject" />
12 <add expression="R:Administrators OR R:Chef"
13 name="DeleteProject" />
16 <add expression="R:Administrators OR R:Chef"
17 name="EditProject" />
18 </rules>
19 </add>
20 </authorizationProviders>
21 </securityConfiguration>
Wie zu sehen ist, sind die einzelnen Regeln nur eine Zeile lang. Aber keine Angst, die Syntax ist einfach und es gibt zu dem das Konfigurationstool in dem sich noch weitere Sachen einfach zusammen klicken und testen lassen. Zur Konfiguration gehört eine solche Abfrage (die Zeilennummer sind nicht von oben):
26 IAuthorizationProvider auth = AuthorizationFactory.GetAuthorizationProvider("ProjectRuleProvider");
27 return auth.Authorize(principal, "EditProject");
Bei Prinzipal handelt es sich um ein IPrinzipal-Objekt, dass zum Windows Nutzer oder zum Web-Nutzer gehört.
An dem Artikel habe ich jetzt eine Woche "gedoktort", dadurch ist er nicht besser geworden. :( MVC macht immer noch sehr viel Spass, aber nun muss ich auch mal an die Dokumentation ran, damit auch mal ein anderer das Zeug pflegen kann. Testfälle formulieren fehlt auch noch. :(
