Zugriff von überall? Authentifizierung ist wichtiger denn je!

Die Gildenarbeit ist inzwischen zu einem festen Bestandteil bei eXXcellent solutions geworden. In vorangegangenen Blogbeiträgen haben wir bereits einige unserer  Gilden in ausführlichen Gildenportraits vorgestellt. Im Einzelnen waren das die Gilden:

• Container, Kubernetes & Cloud Native
• CI/CD
• Technology Radar & Best Practices
• Die Gildenarbeit bei eXXcellent solutions

In diesem Artikel stellen wir die Arbeit unserer Gilde "Authorization, Authentication, Single Sign On (SSO)" vor.

Sind Login-Dialoge und Benutzerverwaltungen nicht langweilige Themen?

Sicherlich stellen sich bei diesen Themen den meisten Leser:innen unweigerlich Fragen wie:

• Wie kann man so ein angestaubtes Thema wie Login und Benutzerverwaltung zum Thema einer Gilde machen?
• Braucht man Gilden nicht in erster Linie, damit die absoluten Spitzen-Expert:innen sich innovative Konzepte für die technischen Lösungen von morgen ausdenken? Sich wie Entdecker:innen mit den allerneuesten Technologien befassen, die bei anderen Software-Ingenieur:innen erst Jahre später ankommen - wenn überhaupt?
• Haben wir denn nicht auf der anderen Seite schon seit Jahrzehnten immer wieder Komponenten für Benutzerverwaltung, Loginseiten und Passwortdialoge gebaut? In fast jedem Projekt wieder? Wofür brauchen wir da eine Expertengruppe?
• Und vielleicht die wichtigste der Fragen: Was haben unsere Kunden davon, wenn wir die Themen rund um Authentifizierung und Autorisierung meisterlich beherrschen? Können das nicht alle? Sollte das nicht selbstverständlich sein?

Fragen und Bedürfnisse

Fragen über Fragen! Und genau mit offenen Fragen fing die Geschichte dieser Gilde auch an: Es war ein kleines Detail in den Abläufen beim Login, das mir nicht klar war. Kein Problem, man kann ja nicht alle Kleinigkeiten ständig parat haben! Dazu hat man ja auch Kolleg:innen, mit denen man sich austauschen kann - also einfach mal nachfragen! Beinahe war es mir peinlich, weil ich mir vorstellte, dass ich so ziemlich der Letzte wäre, der bei diesen grundlegenden Themen noch eine Wissenslücke hat. Dann die Überraschung: So detailliert hatten die meisten noch gar nicht darüber nachgedacht. Hier könnte es sich also lohnen, tiefer zu bohren.

Es gibt mehr zu wissen, als im normalen Projektalltag Platz hat!

Und ja: Eine Benutzerverwaltung, Login-Dialoge usw. werden in jedem Projekt gebraucht. Wie gut wäre es, wenn es hier eine Standardlösung gäbe, die flexibel genug ist, auf die konkreten Anforderungen einzugehen. Die aber gleichzeitig standardisiert genug ist, um nicht in jedem Projekt teure und letztlich ineffiziente Lösungen für das gleiche Problem neu zu erfinden!

Schließlich war auch in Sachen Erwartungen der Kunden nicht alles beim Alten geblieben: Single-Sign-On, Social Login, verteilte Identitäten, Mehrfaktorauthentifizierung und passwortlose Verfahren sind längst nicht mehr nur Spielwiesen für Technikverliebte. Sie sind harte, geschäftliche Anforderungen in vielen Projekten.

Warum wir die Gilde gegründet haben

Die Gilde "Authorization, Authentication, Single Sign On" wurde mit vier Kollegen gegründet, die hier ebenso Bedarf sahen. Sie beschreibt ihre Daseinsberechtigung in einem kurzen Elevator Pitch:

» Mit dem Querschnitt-Thema Authentifizierung/Autorisierung ist in jedem Kundenprojekt ein Risiko und eine Chance verbunden:

Das Risiko ist, dass viel Zeit mit Forschungsarbeit verbracht wird, weil die Standard-Technologien nicht sicher beherrscht werden. Im schlimmsten Fall entstehen so teure, suboptimale Lösungen.

Die Chance ist, dass aktuelle, noch nicht so weit verbreitete Themen wie Social Login, 2FA den Unterschied machen können zwischen einer Lösung, die jeder bauen könnte und einer Lösung, die den Kunden begeistert.

Um das Risiko zu vermeiden und die Chance zu ergreifen ist Voraussetzung, dass wir als Firma sowohl in der Breite die Standardlösungen beherrschen, als auch in der Spitze Experten haben, die aktuelle Techniken tief verstehen. «

© yanalya - freepik.com

Eine kurze Geschichte des Identitätsmanagements

Es ist ein Problem, so alt wie der Einsatz von Computern überhaupt: Softwaresysteme müssen erkennen, wer oder welches System eine bestimmte Aktion ausführen möchte (Authentifizierung). Und sie müssen entscheiden, ob die Aktion erlaubt werden soll (Autorisierung). Es ist interessant zu sehen, wie sich die Strategien zur Lösung dieser Probleme im Lauf der Zeit weiterentwickelt haben. Daher hier ein kurzer Abriss:

Identitätsmanagement lokal und selbstgemacht

In diesem, dem ältesten Modell hat jedes System ein eigenes Identitätsmanagement, das Authentifizierung und Autorisierung in Eigenregie durchführt. So speichert es beispielsweise Benutzernamen und Passwörter selbst - jedes auf seine Weise. Die User müssen sich ihre Zugangsdaten für jedes System merken. Wenn beispielsweise neue Mitarbeiter:innen in einem Unternehmen fünf verschiedene Programme nutzen sollen, müssen in allen fünf Systemen Zugänge mit Benutzernamen und Passwörtern angelegt werden, die sich die Mitarbeiter:innen merken müssen!

Dies war das ursprüngliche Vorgehen: einfach in der Administration, aber umso komplizierter, je mehr Systeme und Anwendungen beteiligt sind. Klingt veraltet? Ist aber heute außerhalb von Unternehmensanwendungen durchaus noch sehr verbreitet: Überlegen Sie einmal, wie viele Internetdienste Sie mit jeweils eigenen Zugangsdaten nutzen. Und natürlich verwenden Sie aus Sicherheitsgründen nicht überall dasselbe Passwort - oder doch?

Zentrales Benutzerverzeichnis ("Directory Services")

Eine Weiterentwicklung ist das zentrale Benutzerverzeichnis. Es enthält die Identitätsinformationen und stellt sie allen Anwendungen (beispielsweise innerhalb einer Firma) zur Verfügung. Die einzelnen Systeme nutzen sie, um die bereits beschriebenen Zugangsentscheidungen zu treffen. Der große Vorteil: Die Administration erstellt den Useraccount genau einmal. Der User erhält anschließend einen Satz von Zugangsdaten, mit denen er sich an allen Systemen, auf die er Zugriff hat, anmelden kann. Eine Passwortänderung wirkt sofort auf alle Systeme. Im Unternehmensumfeld ist das eine große Erleichterung für alle Beteiligten. Das Directory kann als Spezialist für die Verwaltung der sensiblen Identitätsdaten optimal abgesichert werden.

Um diese Anforderungen, wie sie oft im Umfeld von Unternehmen und Organisationen auftreten, umzusetzen, existieren eine Reihe von Ansätzen. Einige arbeiten mit Replikation der Identitätsdaten in die einzelnen Systeme. Am weitaus verbreitetsten sind jedoch Lösungen, die auf Protokolle wie LDAP oder Produkte wie das Active Directory aufsetzen.

Single-Sign-On, Erste Generation

Die vorgenannte Lösung hat zwei Schwächen:

1. Jede einzelne Anwendung muss die Prüfung der Identitätsdaten weiter selbst vornehmen, was leider auch bedeutet, dass sie darauf Zugriff haben muss. Damit muss man allen beteiligten Systemen vertrauen, dass diese sensiblen Daten dort auch optimal geschützt werden.
2. Die Anmeldesitzungen werden nicht vom System verwaltet. Das bedeutet, die User müssen sich an jedem einzelnen System anmelden und bei Inaktivität nochmals neu anmelden, da sie vom System abgemeldet wurden.

Um das zu lösen, tritt Single-Sign-On (SSO) an. Dabei übernimmt der zentrale SSO-Server vollständig das An- und Abmelden und so bekommen die beteiligten Systeme beispielsweise die Passwörter niemals zu sehen. Der SSO-Server stellt stattdessen geschützte, kurz laufende "Tickets" aus, die, auch wenn sie in die falschen Hände geraten sollten, nicht für andere Systeme missbraucht werden können.

Die erste Generation von Single-Sign-On-Systemen war oft mit proprietären Protokollen gebaut und darauf ausgelegt, nur mit der begrenzten Zahl von Anwendungen in einem geschützten Firmennetzwerk zu funktionieren. In einer Zeit, in der die Anzahl der genutzten Dienste wächst und viele Dienste übers Internet angeboten werden, ist das ein Nachteil, der immer mehr ins Gewicht fällt.

Single-Sign-On über offene Protokolle

Um diese Entwicklung zu unterstützen, mussten offene Protokolle her, die konsequent auf das Web setzen. Der Urvater dieser Protokolle war SAML, das es erstmalig möglich machte, SSO-Sitzungen auch über Netzwerk- und Technologiegrenzen hinweg zu nutzen und das auch heute noch eine wichtige Rolle spielt. Den aktuellen Goldstandard stellen aber OAuth2 und OpenID Connect dar, die vor allem dadurch Verbreitung erlangt haben, dass sie von den großen amerikanischen Tech-Companies auch für Endkunden angeboten wurden und damit Web-Single-Sign-On auch außerhalb von Firmen und Organisationen möglich gemacht haben: "Login with Facebook" oder der "Google-Account" sind für heutige Internetnutzer:innen alltäglich.

Dieser Ansatz ermöglicht es, eine zentrale Identität zu haben, die zusammen mit Zugangsdaten wie Passwörtern bei einer Stelle gespeichert sind, der man vertraut - und gleichzeitig bei jedem einzelnen Dienst über lokale Identitäten zu verfügen, die damit verknüpft und durch die Authentifizierungsprozesse der Zentral-Instanz geschützt sind.

© rawpixel - freepik.com

Neue Sicherheitsmechanismen (Zwei- oder Mehrfaktorauthentifizierung, z.B. mit Einmalpasswörtern, Hardwaretoken oder Biometrie, aber auch Dinge wie Audit-Logs etc.) können an einer zentralen Stelle implementiert werden. Die dadurch erhöhte Sicherheit steht sofort allen beteiligten Systemen zur Verfügung, ohne dass dort irgendetwas verändert werden müsste. Die Zusammenarbeit über das Web mit verschiedenen Klassen von Anwendungen wie Smartphone-Apps, clientseitigen Webanwendungen, servergestützten oder lokal installierten Systemen, ist von den Standards explizit vorgesehen. Und die Absicherung der Maschine- zu Maschine-Kommunikation über APIs wird genauso berücksichtigt.

Also ist das Problem gelöst?

So gut der aktuelle Ansatz klingt: Leider ist damit die Arbeit noch nicht getan! Die Entscheidung für ein aktuelles Protokoll ist ein wichtiger Schritt, aber es bleibt genug zu tun. Das beginnt damit, dass Protokolle eben nur Protokolle bzw. Vorschriften und noch keine lauffähige Software sind. Es gilt also Komponenten zu finden, die die einzelnen Teile eines solchen Protokollablaufs auch tatsächlich implementieren. Dabei sollte man von Eigenimplementierungen möglichst absehen: Es stehen sowohl in der Open-Source- als auch in der kommerziellen Software-Welt Komponenten bereit, die die Phase der groben Anfängerfehler bereits hinter sich haben und im produktiven Einsatz vielfach bewährt sind.

Zudem muss es vielleicht gar nicht ein selbst betriebener Teil der Infrastruktur sein: Einige der Dienste können leicht als Webdienst genutzt werden. Dabei wird mindestens ein Autorisierungsserver benötigt, der:

• sich mit einem Identitätsprovider verbinden lässt und
• mit dem die eigene Software als "Client" oder "Relying Party" zusammenarbeitet.

Wenn Zugriffe auf zusätzliche Dienste oder APIs notwendig sind (was häufiger der Fall ist), kommen weitere Komponenten hinzu, die integriert werden wollen.

Sobald die Grundfunktionalität zur Anmeldung steht, müssen weitere Entscheidungen getroffen werden:

• Wie sind die Autorisierungsinformationen (also "wer darf was") verteilt?
• Speichert der Autorisierungsserver nur Namen und vielleicht Rollen der User oder soll er mehr über deren Berechtigungen wissen?
• Wie gehen wir mit datenabhängigen Berechtigungen um?
• Wie erfolgt die Pflege der Identitäten und Berechtigungsinformationen?

Genug zu tun für Projekte, die aktuelle Auth-Verfahren in ihre Software einbauen!

Wie unterstützt die Gilde hier die Projekte?

Mit unserer Gilde "Authorization, Authentication, Single Sign On" können wir Projekte unterstützen, die das Thema "Authentifizierung und Autorisierung" behandeln müssen - und das sind alle Projekte:

• Beratung bei der Auswahl von Protokollen, Technologien, Komponenten und Bibliotheken
• Mitarbeit bei der Konzeption der Auth-Lösung. Hier steht die Integration der bewährten Komponenten in die fachlichen Bausteine der Anwendung im Vordergrund.
• Reviews
• ggf. Unterstützung bei der Umsetzung

Folgende Protokolle und Technologien setzen wir dabei bevorzugt ein:

• OAuth2
• Open ID Connect
• SAML
• Keycloak
• OAuth2-Proxy zur transparenten Einbindung in die Anwendung

In folgenden Szenarien und Architekturen können diese Lösungen eingesetzt werden:

• Integration in clientseitige Webanwendungen (Single-Page-Applications) mit den verschiedenen Frameworks (React, vue.js, UI5, Angular, ...)
• Backendseitige Webanwendungen, z.B. in Java oder Node.js
• Integration in native oder hybride Mobilanwendungen
• Lokal installierte Client-/Server-Anwendungen
• Cloud-native Anwendungen in den Umgebungen der Hyperscaler oder On-Premise
• Integration von Systemen über Schnittstellen (APIs)

Was machen wir mit den Erfahrungen, die wir in der Gilde sammeln? Die Antwort: orchideo | auth

Mit Kunden, deren Anwendungen noch aus älteren Epochen stammen und die auf aktuelle Technologien oder Protokolle setzen wollen oder müssen, stehen wir häufig vor Migrationsaufgaben. Die Erfahrungen, die die Gilde gesammelt hat, fassen wir in unserem Lösungsbaustein orchideo | auth zusammen. Er stellt unsere Vision von einer Komponente dar, die einerseits einen großen Teil der wiederkehrenden Anforderungen abdeckt, andererseits aber so flexibel ist, dass sie in möglichst vielen Szenarien ohne große Anpassungsaufwände eingesetzt werden kann - so wie in unseren Kundenprojekten.

Mehr zu unserem Lösungsbaustein orchideo | auth gibt es demnächst in diesem Blog. Um diesen Artikel nicht zu verpassen, melden Sie sich am Besten gleich hier bei unserem Newsletter an.

Übrigens: orchideo | auth ist ein Bestandteil unseres Paketes orchideo | solutions, welches Komponenten, Frameworks und Services umfasst, die wir, wann immer sinnvoll, in unseren Projekten nutzen, um möglichst schnell und mit hoher Qualität ans Ziel zu kommen.

Mehr zu orchideo | solutions und den einzelnen Lösungsbausteinen gibt es auf unserer Webseite unter exxcellet.de/orchideo-solutions.

Erfahrungen und Ausblick

Die Gildenarbeit hat einen weiteren Vorteil: Die Erkenntnisse aus der "realen Welt" der Projekte fließen in die Gilde zurück und tragen dazu bei, orchideo | auth aktuell zu halten und weiter zu verfeinern, damit wir dem nächsten Projekt und dem nächsten Kunden noch besser helfen können!

Wenn damit eine fruchtbare Koexistenz von Projekten und Gilde auf den Weg gebracht ist, was gibt es dann noch zu tun? Sehr vieles! Denn das Wissen muss aktuell gehalten werden:

Technologien veralten und werden durch neue abgelöst. Es gibt ständig neue Erkenntnisse, neue Einsatzszenarien und neue Standards. Dinge wie Einloggen ohne Passwort klangen einst wie Zukunftsmusik, werden aber mehr und mehr in aktuelle Systeme integriert. So hat beispielsweise die Mehrfaktorauthentifizierung den Sprung von einer Nischentechnologie aus dem Hochsicherheitsbereich in den Mainstream geschafft.

Und damit sind wir wieder am Anfang angelangt - bei den Fragen nach den Details der technischen Funktionsweise:

Wenn man komplexe Komponenten nicht nur verwendet, sondern bis ins Detail versteht, wie sie "im Kern" funktionieren, kann man viel leichter begründete Entscheidungen treffen. Entscheidungen darüber, ob die neue, gehypte Technologie nur eine Luftnummer ist oder ob es sich lohnt, sie weiter zu verfolgen und vielleicht im nächsten Kundenprojekt zu empfehlen.

Die Gilden bei eXXcellent solutions: Gilden Portraits

• Agile Softwareprojekte und Innovation: Gilden bei eXXcellent solutions
  
  
• Von Containern, Orchestern und Wolken: Die Gilde „Container, Kubernetes & Cloud Native“ 
  
  
• Mit CI/CD erhöhen wir die Softwarequalität und verkürzen konstant die Releasezyklen: Die Gilde "CI/CD"
  
  
• eXXcellent solutions Technology Radar: Wegweiser für unseren Kundenerfolg! Die Gilde "Technology Radar & Best Practices"
  
  
• Lernen, um zu Lernen: Die Gilde AI, Machine Learning & Data Science

In der nächsten Folge unserer Artikelserie stellt sich die eXXcellent solutions Gilde "AI, Machine Learning & Data Science" im Portrait ausführlicher vor. Um unsere Gilden Portraits nicht zu verpassen, melden Sie sich am Besten gleich hier bei unserem Newsletter an.

Weitere Informationen