Referenzimplementierung des IsyFact-Bausteins 'Security'

Wie bei der Referenz-Implementierung zum Architektur-Durchstich steht das Keept-it-Simple-Prinzip im Vordergrund. Es wird angestrebt, die Fachlichkeit minimal zu halten.

Darüberhinaus war es das Ziel, die Anzahl der miteinander kommunizierenden Anwendungen, die nötig sind, um die technischen Features des Security-Bausteins zu demonstrieren, sowie die Anzahl der Klassen und Methoden dieser Anwendungen möglichst klein zu halten.

Nutzungsvorgaben, Namenskonventionen, Strukturierungs-Richtlinien werden eingehalten.

Es werden zwei Anwendungen zur Verfügung gestellt:

Die Anwendungen arbeiten mit dem folgenden Berechtigungskonzept

Hinweis: Diese Konstellation bedeutet, dass im Security-Service-Consumer für Aufruf der Update-Funktion des Security-Service-Providers eine Re-Authentifizierung notwendig ist, die dem Aufrufer eine Identität mit den erforderlichen Rollen und Rechten inklusive "PRIV_Recht_A" mitgibt. Das Berechtigungskonzept wurde bewusst so gewählt, sodass ohne das technische Feature einer Re-Authentifizierung die erfolgreiche Ausführung einer Update-Funktion im Service-Consumer nicht darstellbar ist.

Die Security-Service-Provider-Anwendung und die Security-Service-Consumer-Anwendung haben beide ihre eigene pom.xml

Die folgenden Artefakte werden von beiden Anwendungen als Dependencies verlangt:

Security-Service-Provider-Anwendung spezifische Dependencies gibt es zu:

Security-Service-Consumer-Anwendung spezifische Dependencies gibt es zu:

Daran lässt sich erkennen, dass sich die beiden Anwendungen in ihrer untersten Schicht unterscheiden. Im Security-Service-Provider haben wir hier eine Datenbank, im Security-Service-Consumer dagegen einen 'resource-server'.

Alle anwendungsrelevanten Konfigurationseinstellungen sind in Anwendungs-spezifischen application.yml Dateien definiert.

Was den Security-Baustein betrifft, so beinhalten diese Dateien vor allem client-ids und client-secrets. Diese Properties werden in den Anwendungen verwendet und sind in KeyCloak definiert. Mit den application.yml Dateien werden diese Definitionen repliziert.

Weiterhin existiert in beiden Anwendungen eine rollenrechte.xml Datei. Diese Datei wird vom IsyFactBaustein 'Security' ausgewertet, um beim Zugriff auf geschützte Resourcen zu prüfen, ob ein User mit seinen Rollen, die er mit seinem Acess-Token mitbringt, auch die in der '@Secured' Annotation spezifizierten Rechte hat.

Der innere Aufbau von Security-Service-Provider und Security-Service-Consumer entspricht der 3-Schichten-Architektur des Architektur-Durchstichs, wobei im Security-Service-Consumer keine Persistenzschicht, sonderen stattdessen eine Adapterklasse zum Aufruf der REST-Schnittstelle des Security-Service-Providers implementiert ist.

In der folgenden tabellarischen Aufstellung gehen wir nicht mehr auf die Klassen und Interfaces ein, die im Architektur-Durchstich bereits beschrieben sind, sondern wir beschreiben nur noch die Klassen, die für den Aspekt 'Security' eine besondere Rolle spielen.

Neben einer automatisierbaren Qualitätssicherung, die im Rahmen eines professionellen SW-Engineering eine Selbstverständlichkeit sein sollte, möchten wir darauf hinweisen, dass vor allem die API-Tests noch einen weiteren Vorteil bieten: nämlich dem Entwickler zu illustrieren, wie er die technischen Features eines IsyFact-Bausteins nutzt.

Zur Durchführung der Tests werden entweder Spring-Boot-Tests oder Api-Tests ausgeführt.

Voraussetzung für die Ausführung von Spring-Boot-Tests ist, dass die zu verwendende Keycloak-Instanz (manuell) gestartet wurde.

Voraussetzung für die Ausführung von Api-Tests ist, dass neben der Keycloak-Instanz, auch die beiden Anwendungen (Security-Service-Provider und Security-Service-Consumer) gestartet sind. Nur so nämlich lässt sich über API-Aufrufe auch deren REST-Schnittstelle erreichen.

Die nachfolgenden Tabellen geben eine Übersicht über die implementierten Testklassen und deren Testfälle. Zur weiteren Information sollte ein Entwickler die Kommentare im Java-Code heranziehen und sich über den Keycloak-Client die in Keycloak persistierte Konfiguration ansehen.