In einem vorherigen Artikel haben wir uns damit befasst, wie man Keycloak Rollen als Spring Security Authorities verfügbar macht, wenn Spring Boot als Resource Server agiert. In diesem Folgebeitrag betrachten wir nun den Fall, in dem unsere Spring Boot Anwendung die Rolle eines OAuth 2.0 Client einnimmt und einen OAuth 2.0 Login mit Keycloak implementiert. Auch hier wollen wir die Rollen aus Keycloak korrekt mappen.

Supply Chain Security spielt auch im Container Umfeld eine immer wichtigere Rolle. Es gilt dabei die Sicherheit im Sinne von Echtheit und Integrität der (Docker) Images abzusichern.
Typische Supply Chain Angriffsszenarien bei Kubernetes, Docker...

In vielen modernen Anwendungen nutzen wir Keycloak zur Authentifizierung für den Zugriff auf Spring Boot Anwendungen. Dabei werden Benutzer und ihre Rollen in Keycloak gespeichert bzw. von Keycloak bereitgestellt. In einer Spring-Anwendung möchten wir diese Rollen nun nutzen, um den Zugriff auf Ressourcen zu autorisieren. In einem weiteren Blogpost betrachten wir Fall in dem unsere Anwendung als OAuth 2.0 Client agiert und einen OAuth 2.0 Login implementiert.

Fullstack in modern - von Offlinefähigkeit bis hin zu Echtzeitanwendungen. Gemeinsam mit dem Java Magazin haben wir einen Artikelschwerpunkt entwickelt, in dem wir im Rahmen einer Beispielanwendung einige der Technologien vorstellen, mit denen wir auch in Kundenprojekten Architekturanforderungen umsetzen.

Dabei nutzen wir für die Beispielanwendung MQTT als Messagingsystem um Events bis in das browserbasierte Frontend auf Basis von Angular als ein Kommunikationsweg nutzen.

Als Sonderdruck ist der Schwerpunkt im PDF Format als Download am Ende von diesem Beitrag zu finden.

Mit Spring Security können unter anderem Webanwendungen (Spring WebMVC) auf einfache und flexible Weise abgesichert werden. Dabei ist der typische Weg über Security-Filter-Chains die Webschicht von Spring WebMVC mit Spring Security abzusichern. Doch reicht das aus?
Diese rhetorische Frage lässt sich mit vielleicht beantworten: Gibt es keine Programmierfehler oder Logikfehler, so kann das bereits ausreichen. Denn erreicht kein Request unberechtigt die Controller-Schicht, dann kann nichts passieren.

Doch in Zeiten zunehmender Cyberbedrohungen sollte keine Anwendung lediglich durch eine Schicht gesichert werden. Verteidigung in der Tiefe kann dank Spring Security leichtgewichtig mit Method Security umsetzen. Eine deutliche Verbesserung.

In unserem letzten Spring Security Training kam die Frage auf, wie sich dies mit periodischen Aufgaben innerhalb der Spring Anwendung kombinieren lässt. Das soll als Anlass dienen, sowohl periodische als auch asynchrone Ausführung, z.B. durch Message-Queue Nachrichten in Kombination mit Method Security darzustellen.

Container Image sind dank OCI Standard und Verbreitung von Docker und Kubernetes zu dem Mittel der Wahl geworden, um Anwendungen zu verteilen. Dabei verwenden Container Runtimes wie Docker ein geschicktes Verfahren zur Deduplizierung von Daten: Ein Container Image ist in Layer aufgeteilt und diese können unabhängig voneinander verteilt und gespeichert werden.
Da die Layer selbst nicht veränderlich sind, können Layer wiederverwendet werden.

Typischerweise finden sich auch viele Gemeinsamkeiten: Die verwendete Basisdistribution, Laufzeitumgebungen wie Python oder Java und ggf. auch firmenspezifische Konfigurationen wie TLS Zertifikate.

Dabei muss ein Tradeoff beachtet werden: Je mehr Layer, desto mehr Overhead entsteht durch sie. Gleichzeitig ist es um so wahrscheinlicher, dass bei feingranularen Image Layern eine gute Wiederverwendbarkeit ermöglicht wird.

Bei der Auswahl von Base-Images, auf die eigene Anwendungsimages aufgebaut werden sollen, gilt es also darauf zu achten, dass diese möglichst geschickt augeteilt sind und nicht nur aus einem Layer bestehen, der stets vollständig neu geladen und gespeichert werden muss, wenn es Aktualisierungen gibt, aber auch nicht aus zehn oder mehr Layern.

Zur Bestimmung der Anzahl der Layer gibt es verschiedene Ansätze. Am Beispiel eines Java Basisimages, openjdk, werden diese im folgenden betrachtet.

Durch CSP Header (Content Security Policy) lassen sich verschiedene Funktionen des Webbrowsers konfigurieren, um das Verhalten von Nachladen und auch Ausführen zusätzlicher oder dynamischer Inhalte zu beeinflussen. Damit lassen sich typische Einfallstore für Angriffe wie Cross-Site-Scripting (XSS) wirksam abstellen.
Ist die Webanwendung jedoch eine Single Page Anwendung (SPA) und auf dynamische Erzeugung von Inhalten angewiesen, führt eine globale Deaktivierung der Dynamik dazu, dass die Anwendung nicht mehr funktioniert. Es stellt sich daher die Frage, wie zwischen guten und potentiell schädlichen externen und dynamischen Inhalten unterschieden werden kann.

Dazu ist in allen Browsern inzwischen ein Verfahren implementiert, mit dem Entwickler solche Inhalte, die erwünscht sind, expliziert markieren können: sogenannte "Nonce" Markierungen. Aktuelle Frameworks, so auch Angular, bringen dazu auch speziellen Support mit.
Die Implementierung wird in diesem Beitrag anhand von nginx gezeigt.

Container Images sind inzwischen etabliert, um darüber Anwendungen bereitzustellen. Durch das standardisierte Format, einheitliche Schnittstellen und das insgesamt bestehende Ökosystem wird es sehr einfach, Artefakte zu konsumieren und auch bereitzustellen. Jedoch hat das auch Konsequenzen: Die Verantwortung für Patchmanagement, Fehlerbehebungen und Security-Updates verschiebt sich zum Anbieter der jeweiligen Images, da diese mehr, als lediglich die Anwendung selbst beinhalten. Gleichzeitig obligt es dem Konsumenten bzw. Nutzer der Images, sicherzustellen, dass diese aus einer vertrauenswürdigen Quelle stammen und auch nicht zwischendurch verändert wurden.
Diese Aspekte der "Supply-Chain-Security", einem Unterbereich der IT-Sicherheit im Kontext von Containeranwendungen wollen wir uns in diesem und folgenden Artikel widmen.

Bei der Erstinstallation von Keycloak wird im Master-Realm ein Benutzerkonto für einen globalen Administrator angelegt, der über alle Rechte verfügt. Dieser Benutzer darf neue Realms anlegen und alle Realms verwalten. Er ist ungefähr vergleichbar mit dem Superuser root unter Linux. Der Zugang erfolgt über die Admin-Konsole des Master-Realms unter <base_url>/admin bzw. <base_url>/admin/master/console.

Der Master-Realm ist ein spezieller Realm, der es Administratoren erlaubt, mehr als einen Realm auf dem System zu verwalten. Daneben verfügt aber jeder Realm, der in Keycloak erstellt wird, über eigene Admin-Konsole, von der aus dieser Realm verwaltet werden kann.

Sowohl im Master-Realm als auch in jedem anderen Realm können weitere Benutzer mit abgestuften administrativen Rechten angelegt werden.

Im Auslieferungszustand von Keycloak umfassen Benutzerinformationen den Benutzernamen, Vor- und Zunamen sowie die E-Mail-Adresse. Diese Felder waren bis einschließlich Version 23 fest vorgegeben. Kundenspezifische Key-Value-Paare für Benutzer, Rollen und Gruppen konnten zwar definiert werden, aber Keycloak bot weder Validierung noch die Möglichkeit für Benutzer, diese in der Account-Konsole selbst zu ändern. Mit der Einführung von Version 24 werden Benutzerprofile wesentlich flexibler. Deklarative Benutzerprofile, bisher nur hinter einem Feature-Flag verfügbar, werden nun voll unterstützt und erlauben es Administratoren, beliebige Felder zu definieren und zu bestimmen, wer sie bearbeiten darf.

Gerade wenn es um Side-Projects oder Hobbyprojekte geht, ist das Budget oft begrenzt. Dann ist es besonders wichtig, dass keine zusätzlichen Kosten für TLS Zertifikate anfallen.
Im Zentrum eines solchen Projekts steht ein Vue.js-Frontend, das sich mit einer HTTP API verbinden soll. Natürlich mit der erforderlichen Sicherheit, die Transport Layer Security (TLS) bieten kann.

Bislang war ZeroSSL besonders deswegen attraktiv, da keine Rate-Limits kreativer Forschung entgegen standen. Allerdings liefert ZeroSSL seit einiger Zeit fehlerhafte (abgelaufene) Zertifikate aus der Vergangenheit oder auch API Fehler.

Da ACME ein Standard ist, sollte das auch mit anderen Anbietern gehen, und ein weiterer Anbieter ist Google.

Die Suche nach dem idealen Self-Hosted Newsletter-Tool kann herausfordernd sein. Es gibt inzwischen auch sehr viele Produkte mit (im grossen und ganzen) ähnlichem Funktionsumfang. In diesem Beitrag werden drei populäre Lösungen verglichen:

Jedes dieser Tools bietet unterschiedliche Funktionen und Vorteile, aber welches passt am besten zu den Anforderungen moderner Systeme?