Als wir kürzlich in unserem Procurement-System vor der Herausforderung standen, Berechtigungen für Belege zu implementieren, wurde mir wieder einmal bewusst, wie komplex moderne Zugriffskontrolle sein kann. In diesem Artikel möchte ich meine Erfahrungen mit verschiedenen Zugriffskontrollmodellen teilen und erklären, warum wir uns letztendlich für ABAC entschieden haben.
Wer kennt sie nicht – die guten alten Access Control Lists (ACLs)? Sie sind wie eine einfache Türliste am Eingang eines exklusiven Clubs: Entweder du stehst auf der Liste, oder eben nicht. In unserem Procurement-Kontext bedeutete das ursprünglich: Beleg XY – Zugriff für Nutzer A, B und C.
Anfangs erschien das ausreichend, aber schnell wurde klar: So einfach ist unsere Geschäftswelt nicht mehr. Was ist, wenn ein Mitarbeiter nur Belege seiner Abteilung sehen darf? Oder nur Belege unter 10.000€? Mit ACLs würde das bedeuten, für jeden Beleg einzeln festzulegen, wer Zugriff hat – ein administrativer Alptraum.
Role-Based Access Control (RBAC) war der logische nächste Schritt. Statt einzelnen Nutzern direkt Rechte zuzuweisen, definierten wir Rollen wie “Einkäufer”, “Abteilungsleiter” oder “Finanz-Controller”. Das vereinfachte die Administration erheblich – neue Mitarbeiter bekamen einfach die passende Rolle zugewiesen.
Aber auch RBAC stieß an seine Grenzen. Ein Beispiel: Ein Abteilungsleiter sollte nur Belege seiner eigenen Abteilung freigeben können, aber gleichzeitig alle Belege unter 1.000€ sehen dürfen. Mit RBAC müssten wir dafür mehrere spezifische Rollen erstellen – “Abteilungsleiter-IT”, “Abteilungsleiter-HR” etc. – oder komplexe Rollenhierarchien aufbauen.
Attribute-Based Access Control (ABAC) war für uns die Erleuchtung. ABAC berücksichtigt nicht nur den Nutzer und seine Rollen, sondern auch:
Ein Beispiel aus unserer Implementierung: “Ein Abteilungsleiter kann Belege freigeben, wenn:
Die Implementierung von ABAC war definitiv aufwändiger als die vorherigen Ansätze. Wir mussten:
Aber die gewonnene Flexibilität war den Aufwand wert. Änderungen an Zugriffsregeln können nun zentral in Policies verwaltet werden, ohne den Code anzufassen. Neue Geschäftsanforderungen lassen sich durch das Hinzufügen neuer Attribute und Regeln umsetzen, statt neue Rollen oder ACLs zu erstellen.
Für komplexe Enterprise-Anwendungen wie unser Procurement-System ist ABAC meiner Meinung nach alternativlos. Die anfängliche Komplexität wird durch die langfristige Flexibilität mehr als aufgewogen.
Hey there! Are you using SonarQube Community Edition and missing the branch analysis feature that’s only available in the paid versions? Don’t worry – I’ll show you how to add this functionality to your setup. With a community plugin and Docker, you’ll have it running in no time!
Before we dive in, a quick heads-up: The plugin we’ll be using isn’t officially from SonarSource – it’s a community project under the GNU LGPL v3 license. If you’re planning to use this for large, business-critical projects, you might want to check out the official Developer Edition. But for most projects, this solution works perfectly fine!
– Docker and Docker Compose installed on your machine
– Git
– A Bash shell (Git Bash works fine on Windows)
– Basic Docker knowledge is helpful
First, create a directory for your project:
mkdir sonarqube-docker cd sonarqube-docker
Let’s start with the .env file. This is where you set the versions you want to use:
SONARQUBE_VERSION=24.12.0.100206-community BRANCH_PLUGIN_VERSION=1.23.0
Next up is the docker-compose.yml. It’s a bit longer, but don’t worry – you won’t need to modify anything:
services: sonarqube: depends_on: db: condition: service_healthy build: context: . dockerfile: Dockerfile args: - SONARQUBE_VERSION=${SONARQUBE_VERSION} - BRANCH_PLUGIN_VERSION=${BRANCH_PLUGIN_VERSION} container_name: sonarqube ports: - "9000:9000" networks: - sonarnet environment: - SONAR_JDBC_URL=jdbc:postgresql://db:5432/sonar - SONAR_JDBC_USERNAME=sonar - SONAR_JDBC_PASSWORD=sonar volumes: - sonarqube_conf:/opt/sonarqube/conf - sonarqube_data:/opt/sonarqube/data db: image: postgres:16 healthcheck: test: [ "CMD-SHELL", "pg_isready -U sonar" ] interval: 10s timeout: 5s retries: 5 hostname: db container_name: postgres networks: - sonarnet environment: - POSTGRES_USER=sonar - POSTGRES_PASSWORD=sonar volumes: - postgresql:/var/lib/postgresql - postgresql_data:/var/lib/postgresql/data volumes: sonarqube_conf: sonarqube_data: postgresql: postgresql_data: networks: sonarnet:
Now for the Dockerfile – this is where we integrate the plugin into the SonarQube image:
ARG SONARQUBE_VERSION FROM sonarqube:${SONARQUBE_VERSION} ARG BRANCH_PLUGIN_VERSION # Copy the plugin COPY plugins/sonarqube-community-branch-plugin-${BRANCH_PLUGIN_VERSION}.jar /opt/sonarqube/extensions/plugins/ ARG PLUGIN_VERSION ENV PLUGIN_VERSION=1.23.0 ENV SONAR_WEB_JAVAADDITIONALOPTS="-javaagent:./extensions/plugins/sonarqube-community-branch-plugin-${PLUGIN_VERSION}.jar=web" ENV SONAR_CE_JAVAADDITIONALOPTS="-javaagent:./extensions/plugins/sonarqube-community-branch-plugin-${PLUGIN_VERSION}.jar=ce"
The download-plugin.sh script automatically fetches the plugin for you:
#!/bin/bash mkdir -p plugins curl -L -o plugins/sonarqube-community-branch-plugin-${BRANCH_PLUGIN_VERSION}.jar \ https://github.com/mc1arke/sonarqube-community-branch-plugin/releases/download/${BRANCH_PLUGIN_VERSION}/sonarqube-community-branch-plugin-${BRANCH_PLUGIN_VERSION}.jar
And the start.sh script makes launching everything super easy:
#!/bin/bash # Check if .env exists if [ ! -f .env ]; then echo "Error: .env file not found!" exit 1 fi # Load and export environment variables export $(cat .env | grep -v '^#' | xargs) # Check if required variables are set if [ -z "$SONARQUBE_VERSION" ] || [ -z "$BRANCH_PLUGIN_VERSION" ]; then echo "Error: Required environment variables are not set!" echo "Please check SONARQUBE_VERSION and BRANCH_PLUGIN_VERSION in .env file" exit 1 fi # Download plugin ./download-plugin.sh # Start Docker Compose docker-compose up -d
Make the scripts executable:
chmod +x download-plugin.sh start.sh
Now just run the start script:
./start.sh
The script takes care of everything for you:
– Checks if all settings are correct
– Downloads the plugin
– Starts the Docker containers
After a few seconds, you can access SonarQube:
– URL: http://localhost:9000
– Login: admin
– Password: admin (you’ll need to change this on first login)
Now you can use branch analysis in your projects. Just specify the branch name when running a scan:
sonar-scanner \ -Dsonar.projectKey=my-awesome-project \ -Dsonar.branch.name=feature/new-feature
1. SonarQube won’t start? Check the logs:
docker-compose logs sonarqube
2. On Linux, you might need this setting:
sudo sysctl -w vm.max_map_count=262144
3. Plugin not found? Check the plugins directory:
ls -l plugins/
That’s all there is to it! You now have a fully functional SonarQube installation with branch analysis. I’m using this setup myself for various projects and it works great.
Remember: For larger enterprises, the Developer Edition might be the better choice. But for most projects, this solution is more than adequate!
– The Community Branch Plugin on GitHub
– Official SonarQube Documentation
– SonarQube on Docker Hub
Nach 20 Jahren PHP-Entwicklung ist es Zeit für Veränderung. Ich habe mich entschieden, Knowledgeroot komplett in Java neu zu entwickeln. Das bewährte System zur Wissensverwaltung erhält damit eine moderne technische Basis, während die Funktionalität erhalten bleibt.
Die Entscheidung ist mir nicht leicht gefallen, aber die Vorteile einer Neuentwicklung überwiegen. Nutzer von Knowledgeroot werden sich in der neuen Version sofort zurechtfinden – die bewährten Funktionen wie Baumstruktur, Rechteverwaltung und das vertraute Layout bleiben bestehen. Was sich ändert, ist nur das technische Fundament.
Die bisherige PHP-Version wird unter www.knowledgeroot.org archiviert und bleibt für bestehende Installationen verfügbar. Die neue Entwicklung findet komplett offen auf GitHub statt.
Als Software-Entwickler stehe ich täglich vor der Herausforderung, die richtige Balance zwischen technischer Exzellenz und praktischer Umsetzbarkeit zu finden. In diesem Artikel möchte ich meine Erfahrungen teilen, wie man eine nachhaltige und wartbare Software-Architektur entwickeln kann, auch unter realen Bedingungen und Zeitdruck.
Bevor wir uns in die technischen Details stürzen, sollten wir uns zunächst die wichtigsten Fragen stellen:
Diese fundamentalen Fragen ermöglichen es uns, erste architektonische Entscheidungen zu treffen. Ein Beispiel aus unserer Praxis: Wir entwickeln Zusatzsoftware zur Datenextraktion aus ERP-Systemen. Da diese Software nicht direkt von Endbenutzern bedient wird, können wir hier andere architektonische Maßstäbe anlegen als bei einer benutzerorientierten Anwendung.
In meiner täglichen Arbeit beobachte ich immer wieder verschiedene Gründe für suboptimale Architekturentscheidungen:
Eine meiner wichtigsten Erkenntnisse: Arc42 als Dokumentationsframework kann wahre Wunder bewirken. Es hilft uns dabei:
Noch bevor die erste Zeile Code geschrieben wird, haben wir damit eine klare Zieldefinition für unsere Applikation.
Ein weiterer entscheidender Punkt ist die Priorisierung: Die fachliche Implementierung sollte immer vor der technischen Umsetzung stehen. Konkret bedeutet das:
Entwickler sollten sich intensiv mit modernen Konzepten auseinandersetzen:
Diese Konzepte helfen dabei, Architekturentscheidungen besser zu verstehen und nachhaltigere Software zu entwickeln.
Eine realistische Betrachtung des Zeitfaktors ist essentiell. Dabei gibt es zwei Perspektiven:
Mein Vorschlag: Statt nur nach Entwicklerschätzungen zu fragen, sollten wir auch die Gegenfrage stellen: “Wieviel sind Sie bereit zu investieren, um dieses Feature zu bekommen?” Diese Herangehensweise führt oft zu produktiven Diskussionen und realistischeren Erwartungen.
Zusammenfassend lassen sich folgende Kernpunkte festhalten:
Der Weg zu einer besseren Software-Architektur ist nicht einfach, aber er lohnt sich. Bei uns im Team sehen wir bereits deutliche Fortschritte, und ich bin zuversichtlich, dass wir auf dem richtigen Weg sind.
Dieser Artikel basiert auf meinen persönlichen Erfahrungen in der Software-Entwicklung. Ich freue mich über Ihre Gedanken und Erfahrungen zu diesem Thema!
Mit Freude kann ich verkünden, dass ich Ende dieses Jahres einen wichtigen beruflichen Meilenstein erreicht habe: Die erfolgreiche Zertifizierung zum Certified Professional for Software Architecture – Foundation Level (CPSA-F).
In den Monaten November und Dezember durchlief ich sowohl die intensive Schulung als auch die anspruchsvolle Prüfung. Der CPSA-F bildet dabei die Grundlage des international anerkannten Zertifizierungsprogramms des iSAQB (International Software Architecture Qualification Board) und vermittelt essenzielle Grundlagen der Software-Architektur.
Die Foundation Level Zertifizierung bestätigt fundierte Kenntnisse in:
Die Zertifizierung war nicht nur eine formale Bestätigung meiner Fähigkeiten, sondern auch eine wertvolle Lernerfahrung. Die strukturierte Auseinandersetzung mit Best Practices und etablierten Methoden der Software-Architektur hat meinen professionellen Horizont deutlich erweitert.
Mit diesem Foundation Level ist der Grundstein für weitere Spezialisierungen im Bereich Software-Architektur gelegt. Die erworbenen Kenntnisse werde ich in künftigen Projekten gezielt einsetzen und kontinuierlich vertiefen.
Und hier nach unserem Video auch endlich die Fotos von unserem Zugspitzaufstieg über das Höllental. Wie im Video schon erwähnt haben wir die Tour auf 2 Tage verteilt. Die Übernachtung haben wir auf der Höllentalangerhütte gemacht. Leider musste man dieses Jahr einiges mehr an Gepäck für Schlafsack und Co. einberechnen. Aber wir haben es geschafft und möchten so schnell wie möglich noch mal…
Am letzten Tag im Urlaub ging es für alle noch mal durch das Höllental auf zur Höllentalangerhütte. Wie immer sehr beeindruckend und lecker auf der Hütte.
Das für alle Kinder wohl aufregendste Ereignis im Urlaub. Der Schöngänge Klettersteig auf den Bernadeinkopf. Wir haben uns gut gesichert und es hat allen einen riesen Spaß gemacht. Die Kinder möchten mehr davon
Der Kramer war geplant. Geworden ist es der Königsstand. Eine einfache Wanderung mit einem schönen Ausblick auf Garmisch und Farchant,
Für uns ging es auch durch die Partnachklamm und durch das Reintal. Leider hatten wir nicht ganz Glück mit dem Wetter. Aber die Partnachklamm war schon sehr beeindruckend.