Thomas Mahringer Selbstständig

Für Applikationen, die auf Azure laufen, kann im Azure-Portal relativ komfortabel eine Authentifizierung zugeschaltet werden.

Grundvoraussetzungen für jede Applikation sind Authentifizierung und Autorisierung, also wie ein Benutzer (oder allgemeiner: ein Client) beweist, dass er wirklich der ist, der er vorgibt zu sein, und wie man feststellt, welche Rechte er in der Applikation hat. Es gibt viele Ansätze dafür, angefangen bei selbstgeschnitzten Lösungen über klassische Session-basierte Sicherheit bis hin zu Identity Provider Frameworks. Aber Spaß machen sie (zumindest den meisten Entwicklern) nicht so wirklich.

Wie oft haben Sie in Ihrem Entwicklerleben schon verschiedene Authentifizierungsmechanismen umgesetzt oder in Ihre App integriert? Es ist irgendwie ein notwendiges Übel und macht mir persönlich so keinen rechten Spaß. Ich würde mir wünschen, dass ich bei Platform oder Function as a Service einfach die Authentifizierung und Autorisierung einschalten und natürlich noch entsprechend konfigurieren kann (Rollen, Zugriffsrechte, ACLs oder was auch immer). Da wir uns in unseren Projekten auf Single-Page-Web-Apps konzentrieren, sollen diese auch im Mittelpunkt der Artikelserie stehen. Nach der Überlegung, welche Möglichkeiten mit welchen Vor- bzw. Nachteilen es gibt, schauen wir uns an, wie Azure AD (Active Directory) B2C (Business to Consumer) das Problem löst und wie wir es in unsere Apps integrieren können.

Authentifizierung in Web-Apps

Klassische Web-Apps verwenden nach wie vor oft Session-basierte Authentifizierungsmechanismen. Der Benutzer gibt im UI seine Credentials (z. B. Benutzername und Passwort) ein, die über HTTPS an den Server übertragen werden. Je nach Plattform und Authentifizierungs-Framework durchläuft die Anmeldung unterschiedliche Pfade, aber im Kern passiert Folgendes:

  • Das Backend nimmt die Credentials entgegen.
  • Es sucht den passenden Benutzer (z. B. in einer Benutzerdatenbank oder einem Benutzer-Service). Der Benutzer enthält zumindest den Benutzernamen und einen Hash seines Passworts (Passwörter im Klartext zu speichern ist bekanntlich keine gute Idee).
  • Das Backend führt auf das vom Client übertragene Passwort eine Hash-Funktion aus und vergleicht das Ergebnis mit dem Passwort-Hash des zuvor aus dem Benutzer-Service geladenen Benutzers.
  • Falls es übereinstimmt, wird am Server ein Session-Objekt mit eindeutiger Kennung erzeugt.
  • Die ID der Session wird in einen Session-Cookie-Header geschrieben, der zum Client übertragen wird. Der Client (Browser) sendet die Session bei zukünftigen Requests an den Server. Dieser kann aufgrund der vorhandenen Session darauf schließen, dass der Client authentifiziert ist.

Allerdings ist der Session-basierte Ansatz natürlich nicht stateless, da der Server eine Session pro Benutzerverbindung halten muss.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Windows Developer 8.19 - "Apps - schick und sicher"

Alle Infos zum Heft
579898728Applikationen mit Azure Active Directory B2C absichern
X
- Gib Deinen Standort ein -
- or -