Probleme dieser Art sind für Mitarbeiter:innen aus dem IT-Service keine Seltenheit. Gerade wenn das, was der Kunde auf seiner Oberfläche sieht, von seinen Berechtigungen und Rollen abhängt. So kann es vorkommen, dass der Kunde im Front-End eine ganz andere Ansicht seines Social Intranets hat, als der bemühte Admin im Back-End. Wie kann dieser es nun schaffen, das System durch die Brille seines Kunden zu sehen? Um Probleme dieser Art schnell lösen zu können, gibt es in komplexen Softwaresystemen oft eine Funktion, mit der Admins oder Service Mitarbeiter arbeiten: Impersonation. Diese ermöglicht es dem Admin, mit einem Klick in die Rolle eines Benutzers zu schlüpfen und alles genau so zu sehen, wie der Benutzer es sehen würde. Man kann sich das ähnlich vorstellen, wie das Teilen des Bildschirms in einer Video-Konferenz oder bei Anwendungen wie AnyDesk und TeamViewer. Jedoch bietet nicht jedes Softwaresystem diese Möglichkeit. Eine typische Kundenanforderung kann daher so aussehen, dass ein bestehendes System um genau dieses Feature erweitert werden soll. Ziel ist es, so dem Kunden und seinen Anforderungen schneller gerecht zu werden. Schauen wir uns dazu einen konkreten Use Case an:  Wir leisten derzeit Entwicklungs-Support bei einem Kunden, der die Social-Intranet-Lösung unseres Technologie-Partners Coyo im Einsatz hat. Die Impersonate-Funktion ist bei Coyo nicht standardmäßig vorhanden – ein Workaround muss her!

Um die Impersonate-Funktion nun in das bestehende Sicherheitssystem von Coyo zu integrieren, bedarf es eines kleinen, geschickten Eingriffes in das Back-End.

Alles, was bei Coyo mit Authentifizierung (Wer bin ich?) und Autorisierung (Was darf ich?) zu tun hat, wird mit dem äußerst komplexen aber flexiblen Spring-Security-Framework umgesetzt. Dank der vorausschauenden Architektur lassen sich nachträglich problemlos Erweiterungen und Änderungen durchführen, was sich bei der Umsetzung der Impersonate-Funktion als sehr hilfreich erwiesen hat. Wenn ein Benutzer nun mit Coyo interagiert, werden im Hintergrund jede Menge Requests an das Back-End gesendet. Spring-Security kann man sich bildlich als eine Kette von Filtern vorstellen, durch die solche Requests vom Benutzer durchgereicht werden. Jeder Filter hat eine andere Aufgabe und reagiert nur auf einen Request, wenn dieser bestimmte Merkmale besitzt. So gibt es beispielsweise für jede Authentifizierungsmethode einen Filter, der die nötigen Schritte einleitet.  Für die Impersonate-Funktion muss jetzt nur ein weiterer Filter in die Kette eingegliedert werden. Kommt nun die Anfrage eines Benutzerwechsels, wird in der Filterlogik zunächst geprüft, von wem die Anfrage kam und ob dieser User überhaupt die entsprechende Berechtigung dazu hat. Falls ja, wird anschließend in der serverseitig gespeicherten Session vermerkt, wer nun der neue und wer der alte Benutzer ist. Jede weitere Anfrage, die mit dieser Session in Verbindung gebracht wird, wird mit dem neuen Benutzer und seinen Berechtigungen durchgeführt. Ab sofort sehen der Kunden-Nutzer und der Admim ein exakt identisches Bild ihrer Oberfläche vor sich. Ein Wechsel zurück zum alten Benutzer kann nun problemlos und jederzeit erfolgen, da sich die entsprechenden Informationen des alten Benutzers ja bereits in der Session befinden.

So einfach kann’s gehen!

Gerade bei Coyo macht die Impersonate-Funktion Sinn, da es ein umfangreiches Rollen- und Berechtigungskonzept gibt. Dieses hat einen starken Einfluss darauf, was die User auf ihrer Oberfläche sehen. Der Kunde kann nun in seinem angepassten Coyo-Intranet die Berechtigung der Impersonate-Funktion an ausgewählte Mitarbeiter aus dem IT-Service verteilen. Bei mehreren hundert Mitarbeitern kann das eine enorme Entlastung sein, da viele Probleme mit dieser Funktion nun sehr schnell von erfahrenen Mitarbeitern gelöst werden können.

Haben Sie Fragen zum Thema Social Intranet? Wir beraten Sie gerne!