ASP.NET Identity: gut, aber (noch) nicht gut genug

2005 wurde das ASP.NET-Membership-System in ASP-NET 2.0 eingeführt. Mit ASP.NET Membership übernahm ASP.NET die Grundauthentifizierungs- und Autorisierungslogik für uns. Ich bin der Meinung: gut, aber noch nicht gut genug.

ASP.NET Membership wurde für Forms-Authentication und SQL Server entworfen. Mit der Zeit waren diese Beschränkungen nicht mehr ausreichend und ASP.NET Membership machte den Übergang auf eine offenere Infrastruktur nicht möglich. ASP.NET Membership hat folgende Beschränkungen:

• Fixes Datenbankschema
• Custom Providers sind schwer zu implementieren
• Nicht kompatibel mit OWIN

Mit WebMatrix wurde in Visual Studio 2008 ASP.NET SimpleMembership eingeführt. Simple Membership erlaubt eine gewisse Flexibilität, jedoch blieben einige Beschränkungen bestehen:

• Nicht einfach implementierbar für nicht relationelle Datenbanken
• Immer noch nicht kompatibel mit OWIN
• Nicht erweiterbar

Mit Visual Studio 2013 präsentierte Microsoft ASP.NET Identity:

• Eine einzige Plattform für MVC, Web Forms, Web API, Web Pages und SignalR
• Implementierbar in Phone-, Store- oder Hybrid-Applikationen
• Einfach erweiterbar
• Verschiedene Persistenzmöglichkeiten:
  • EF Code First (standardmässig)
  • Schema-Flexibel
  • SharePoint, Azure Tables, NoSQL und andere
• Unit-Test-bar
• Claims-fähig
• Social-integrierbar
• Azure-AD-kompatibel
• OWIN-integrierbar
• NuGet-installierbar

Nicht gut genug

Eine Menge neuer Fähigkeiten! Warum behaupte ich also, ASP.NET Identity sei nicht gut genug? Man kann es auch anders formulieren: Warum sollten wir mehr erwarten? Ich stelle mir zwei Fragen.

1. Warum verwenden wir ein eingebautes Identity Management Framework?

Weil wir unsere Ressourcen auf die Applikationslogik beschränken möchten und die schwierige Sicherheitsfunktionalität den Sicherheitsexperten überlassen.

2. Welche «schwierige Sicherheitsfunktionalität» ist gemeint?

Damit meine ich eine Reihe von Punkten, die ein modernes Sicherheits-Framework für uns übernehmen sollte:

• Benutzer und Passwörter verwalten und speichern: Persistenz und Verwaltung von Benutzer und deren Passwörter
• Profile verwalten und speichern: Persistenz und Verwaltung von Benutzerprofil-Informationen
• Rollen verwalten und speichern: Persistenz und Verwaltung von Rollen und Benutzerangehörigkeiten
• E-Mail- Kontoüberprüfung: Sicherstellung der Angehörigkeit eines E-Mail-Kontos
• Kennwort zurückzusetzen: Was passiert, wenn ein Benutzer sein Passwort vergisst?
• Benutzername-Erinnerung: Was passiert, wenn ein Benutzer seinen Benutzernamen vergisst?
• Kontosperrung: Was geschieht, wenn ein Administrator ein Konto sperren muss?
• Prävention von Passwortraten: Wie erkennen (bzw. vermeiden) wir Versuche, ein Konto durch Wiederholungen zu raten?
• Konto schliessen/löschen: Wie lassen wir einen Benutzer sein Konto schliessen oder löschen?
• Moderne Passwortspeicherung (OWASP): Wie können wir Passwörter sicher speichern?
• Handy-Prüfung: Sicherstellung der Angehörigkeit einer Handy-Nummer
• Zwei-Faktor-Authentifizierung: Um die Sicherheit zu verbessern, wollen wir dem Benutzer zusätzliche Mittel geben, um seine Identität beweisen zu können
• Zertifikatsbasierte Authentifizierung: Benutzer-Authentifizierung mit Zertifikaten
• Auditing: Wie können wir die Veränderungen der Benutzerkonto-Informationen kontrollieren?
• Tracing: Wie können wir Ausfälle im Identitätsmanagement und dem Authentifizierungssystem verfolgen?

ASP.NET Identity unterstützt nur die ersten drei Punkte! Auf die restlichen Punkte wird in ASP.NET nicht eingegangen. Ich hoffe, dass sich ASP.NET Identity mit der Zeit weiterentwickelt Richtung «richtiges» Authentication-Framework und wir uns dadurch auf unsere Arbeit konzentrieren können: die Applikationslogik.

Fazit

Die neuen Persistenz-Möglichkeiten, die Erweiterbarkeit und die OWIN-Integration sind ein grosser Fortschritt gegenüber vorherigen Versionen dieser ersten ASP.NET Identity. Geben wir Microsoft eine Chance und warten wir auf den nächsten Release.