Dirk Dorsch Selbstständig

Neben weiteren Standardanforderungen wie eine Remember-me-Funktion sind auch wesentlich komplexere und sicherheitsrelevantere Features wie CSRF Protection out of the Box in das Projekt integriert.

Welches Passwort hatte ich da nochmal genommen? Ich soll mich schon wieder registrieren? Warum in aller Welt muss ich dafür jetzt einen Facebook-Account haben? So oder ähnlich fällt oft die erste Reaktion auf eine neue Log-in-beschränkte Applikation aus. Restriktive Bereiche in Anwendungen oder Communities haben aber durchaus ihre Daseinsberechtigung. Was auf den ersten Blick nach viel Arbeit aussieht, lässt sich mit Spring Security und Spring Boot schnell integrieren.

Ein wesentlicher Aspekt heutiger Webanwendungen oder auch REST-APIs, egal ob für mobile Apps oder im Kontext von Microservices, ist die Sicherheit. Springbasierte Applikationen bedienen sich hier häufig des De-facto-Standards Spring Security. Spring Security integriert die Sicherheitsbelange in das Spring Framework und ermöglicht es, Webseiten oder APIs abzusichern. Hierbei lassen sich verschiedene Benutzerdatenbanken anbinden. Neben einem Enterprise LDAP kann ebenso jede beliebige Datenbank zur Nutzerhaltung eingesetztwerden. Im B2C-Bereich sollte dem Nutzer nicht zwingend noch ein Account bei irgendeiner Website zugemutet werden. Eine Vielzahl der Internetnutzer hat bereits bei der einen oder anderen Social-Media-Plattform einen Account. Wenn auch nicht unbedingt immer als alleinige Option, gehört es dennoch zum guten Ton, eine Alternative in Form eines „Sign-in with Facebook/ Twitter/GitHub/Google/LinkedIn etc.“ anzubieten.

Social-Log-ins übernehmen im Internet faktisch die Rolle eines Single Sign-ons. Meist über OAuth wird der Authentifizierungs-Request zum entsprechenden Provider weitergeleitet und mit einem Token beantwortet. Einige, aber nicht alle Social-Media-Kanäle implementieren darüber hinaus die OpenID-Spezifikation und ermöglichen es so, applikationsseitig gegen ein definiertes Modell des Benutzerprofils zu entwickeln.

Während das Urgestein Kerberos seine Daseinsberechtigung in der Active-Directory/LDAP-basierten Absicherung innerhalb einer Unternehmensinfrastruktur hat, ist OAuth neben der Absicherung einer (Micro-)Service-Umgebung insbesondere für Single-Sign-on-Szenarien in der Cloud geeignet. Konzeptionell basieren Kerberos und OAuth, aber auch SAML, auf dem gleichen Prinzip. Ein zentraler Server verwaltet die Nutzeridentitäten und stellt für Anfragen eine Art Sicherheitsbürgschaft aus. Angebundene Systeme leiten die Anfragen an das zentrale System, an dem sich ein Nutzer dann anmeldet. Nach erfolgter Prüfung stellt der Identity-Provider dem Aufrufer ein Token, respektive ein Ticket aus. Dieses wird bei allen weiteren Aufrufen übermittelt und serverseitig an der Securityinstanz validiert. Dem Nutzer der Systeme genügt so ein zentraler Account, um eine Vielzahl von Systemen zu nutzen.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 4.18 - "Security First"

Alle Infos zum Heft
579830798Social-Log-ins und Zugriffsrechte in Webanwendungen
X
- Gib Deinen Standort ein -
- or -