Wäre es manchmal nicht verlockend, für einen Moment in jemandes Haut zu schlüpfen, um besser zu verstehen, wie sie/er die Welt sieht? Dieser Wunsch kommt auch immer wieder im Zusammenhang mit Software auf. Zum Beispiel, wenn ein Kunde den Kundendienst einer Tierhandlung anruft und meldet, er sei auf der Website eingeloggt, sehe aber keine Tiere mehr. Und die Mitarbeiterin sich auf der gleichen Webseite einloggt und einen ganzen Zoo von Tieren sieht und nicht versteht, was der Kunde hat. Gäbe es für die Mitarbeiterin eine Möglichkeit, per Mausklick auf die reduzierte Kundensicht zu wechseln, würde sie sehen, dass in dieser Darstellung tatsächlich keine Tiere mehr erscheinen: alle bereits verkauft – und deshalb nur noch für interne Mitarbeiter sichtbar.

Das Beispiel mag etwas an den (Hamster)haaren herbeigezogen sein. Eine kurzzeitige Beschränkung oder Filterung der eigenen Benutzerrechte aber, um eine Applikation temporär durch die Brille eines anderen Benutzers zu sehen, wäre oft von grossem Wert und würde zu mehr Verständnis für andere Anwendergruppen führen. Nicht zuletzt auch für Entwickler, die dann ihre Applikation mit verschiedenen Berechtigungen testen könnten, ohne unzählige Benutzerkonten anlegen und zwischen diesen hin- und herwechseln zu müssen.

Was braucht es, um so einen – sagen wir Autorisierungsfilter – umzusetzen? Im Folgenden soll eine mögliche Lösung skizziert werden am Beispiel einer Web-Applikation mit Angular-Frontend und ASP.NET-Core-Backend.

Lösungsskizze

Schauen wir uns an, wie unser Tierhandlungsbeispiel mit einem Autorisierungsfilter in groben Schritten ablaufen würde:

1. Die Tierhandlungsmitarbeiterin loggt sich via einen Identity Provider in die Angular-Web-Applikation ein. Im JWT-Access-Token, der ihr dabei ausgestellt wird, sind (wie bisher) folgende Rollen enthalten:

   "role": [ "ShowAvailableAnimals", "ShowSoldAnimals", "CreateAnimals" ],

2. Die Angular-Applikation ruft neu vom REST-Backend zusätzlich die verfügbaren Autorisierungsfilter ab. Sie erhält folgende Liste:

   [
     { "Id": "Customer", "FilteredUserRoles": [ "ShowAvailableAnimals" ]},
     ...
   ]
   

3. Die Mitarbeiterin möchte auf die Kundensicht wechseln und wählt deshalb im Menü der Angular-Applikation den Autorisierungsfilter mit der ID «Customer» aus.
4. Die Angular-Applikation speichert in einer Service-Variable die aktivierte Autorisierungsfilter-ID und leitet zurück auf die Hauptseite. Die Berechtigungsprüfung im Angular-Routing (eine Implementation vom Angular-Typ CanActivateFn) stellt fortan sicher, dass die Mitarbeiterin nur noch jene Pfade aufrufen darf, die für Rollen zugänglich sind, die sowohl in ihrem JWT-Access-Token als auch im aktiven Autorisierungsfilter «Customer» enthalten sind. In diesem Fall ist das die Rolle «ShowAvailableAnimals».
   Die Angular-Routing-Definition könnte in etwa folgendermassen aussehen:

   const routes: Routes = [
     {
       path: 'animals',
       component: AnimalsComponent,
       // Lambda-Ausdruck vom Typ CanActivateFn prüft, dass die
       // Rolle ShowAvailableAnimals gleichzeitig im JWT-Access-Token
       // enthalten ist UND im aktiven Autorisierungsfilter
       canActivate: [authorizedToShowAvailableAnimalsFn]},
     },
     ...
   ];
   

5. Für den Aufbau der Übersichtsseite der Tiere setzt die Angular-Komponente nun zwei REST-Aufrufe ans Backend ab:
   1. GET /api/AvailableAnimals
   2. GET /api/SoldAnimals (die Angular-Applikation könnte diesen Aufruf auch direkt unterbinden, wenn sie weiss, dass er nicht erlaubt ist für die Rollen des Filters «Customer»)
6. Bevor die Angular-Applikation die beiden REST-Anfragen abschickt, fügt eine registrierte Implementation des Angular-Interfaces HttpInterceptor automatisch zwei Werte in den Header des http-Requests ein. Erstens den JWT-Access-Token der Benutzerin. Und zweitens den Namen des aktiven Autorisierungsfilters (via ein selbst definiertes http-Header-Attribut X-Authorization-Filter). Der http-Header der REST-Anfragen sieht danach folgendermassen aus:

   Authorization:          Bearer eYJhb…
   X-Authorization-Filter: Customer
   ...

7. Im Backend (ASP.NET Core) sind sämtliche REST-Methoden durch ein neu entwickeltes [AuthorizeWithRoleFilter]-Attribut gesichert. Dieses implementiert das ASP.NET-Core-Interface IAsyncAuthorizationFilter. Das Attribut [AuthorizeWithRoleFilter] berücksichtigt (im Gegensatz zum gewöhnlichen [Authorize]-Attribute) nur jene Rollen, die gleichzeitig dem Access-Token und dem im http-Header angegebenen X-Authorization-Filter zugeordnet sind. Das führt bei den beiden Aufrufen zu folgendem Ergebnis:
   1. [AuthorizeWithRoleFilter(Roles=“ShowAvailableAnimals“)]
      GET /api/AvailableAnimals
      Status-Code 200 (OK) – Liste der verfügbaren Tiere wird zurückgeliefert
   2. [AuthorizeWithRoleFilter(Roles=“ShowSoldAnimals“)]
      GET /api/SoldAnimals
      Status-Code 401 (Unauthorized)
8. In der Angular-Applikation sieht die Tierhandlungsmitarbeiterin nun nur noch die verfügbaren Tiere, die auch der Kunde sehen würde. Die verkauften Tiere sind verschwunden.
   Bis sie den Autorisierungsfilter wieder deaktiviert.

Wichtig bei der Umsetzung ist, dass immer nur die Schnittmenge der Rollen aus dem Access-Token und der Rollen, die dem aktiven Autorisierungsfilter zugeordnet sind, berücksichtigt werden darf. Es darf auf keinen Fall passieren, dass ein Benutzer durch einen Autorisierungsfilter implizit zusätzliche Rollen erhält, die nicht in seinem Access-Token enthalten sind. Andernfalls könnte sich ein Angreifer durch Setzen eines Autorisierungsfilters im http-Header sehr einfach Zugriff auf geschützte Daten verschaffen.

Fazit

Die Umsetzung eines Autorisierungsfilters erzeugt initial einen gewissen Aufwand, sowohl im Frontend, als auch im Backend. Dazu sind hauptsächlich ein paar Interfaces bzw. Lambdatypen zu implementieren, die danach aber immer wieder verwendet werden können. Ist diese Infrastruktur einmal implementiert, können Benutzer mit erweiterten Rechten die Applikation sehr bequem auf eine Benutzersicht mit limitierten Rechten umstellen, um Probleme nachzuvollziehen. Auch beim Testen ist eine solche Funktionalität sehr hilfreich. Besteht später der Bedarf, die Applikation weiterzuentwickeln, bleibt der Zusatzaufwand minimal.

Die meisten Entwickler haben in ihrem Entwickler-Leben schon einmal Login-Funktionalität erstellt. Meistens startet dies mit einer einfachen Login Seite. Aber wie so häufig bei Softwareentwicklung erscheinen plötzlich weitere Anforderungen:

• Benutzer müssen sich jetzt auch registrieren können.
• Benutzer müssen ihr Passwort über Mail zurücksetzen können.
• Wir müssen sicherer werden: Das Benutzerkonto muss nach 10 gescheiterten Anmeldeversuchen deaktiviert werden.
• etc.

Und jetzt haben wir alle diese Anforderungen, welche häufig nicht unsere Core-Domäne wiederspiegeln. Sprich wir wollen diese Anforderungen nicht in unserer Applikation umsetzen.

Tool einsetzen

Anstelle diese Anforderungen selber umzusetzen, können wir ein Tool benutzen, welches uns diese Arbeit abnimmt. In diesem Blog stelle ich ein solches Tool kurz vor.

Aber was sind die Anforderungen an ein solches Tool?

• Zentralisierte Verwaltung
  Wir wollen Identity and Access Management zentralisiert durchführen. Nicht jede unserer Anwendung soll Benutzer, Rechte, Rollen, etc. verwalten.
• Standard Protokolle
  Wenn wir Standart-Protokolle verwenden, haben wir die Möglichkeit in Zukunft auch Anwendungen an unser Tool anzuschliessen. Ausserdem haben solche Protokolle eine höhere Wahrscheinlichkeit, sicher zu sein.
• Single-Sign On / Single-Sign Off
  Benutzer sollten sich nur einmal einloggen bzw. ausloggen müssen.
• Clustering
  Wenn unser Tool schon zentral eingesetzt wird, sollte es auch mittels Clustering skalierbar und verfügbar sein.

Keycloak

Keycloak ist ein Open Source Identity and Access Management Tool welches die Protokolle OpenID Connect, OAuth 2.0 und SAML 2.0 umsetzt. Die oben erwähnten Anforderungen werden erfüllt.

In Keycloak werden sogenannte Clients konfiguriert. Diese Clients dienen als Adapter für Anwendungen, welche von Keycloak Tokens lösen oder verifizieren wollen.

Auf Applikationsseite muss konfiguriert werden, wie auf diese Clients zugegriffen worden soll. Dabei existieren diverse Implementationen für verschiedenste Anwendungen:

• Java:
  • Tomcat
  • Jetty
• JavaScript
• JS
• C#
• Android
• iOS

Der Benutzer muss bei OAuth 2.0 seine Credentials bei Keycloak direkt angeben. Dabei wird ihm folgender Login-Screen präsentiert:

Login Screen für Keycloak

Konfiguration der Applikation

Je nach Client-Type müssen verschiedene Angaben gemacht werden, aber die Konfiguration hat mindestens folgende Inhalte:

• realm: Umgebung innerhalb einer Keycloak Instanz
• resource: Client in Keycloak
• auth-server-url: URL von Keycloak

Im Rahmen dieses Blog-Posts wurden zwei Beispiel-Projekte erstellt um die Applikationsseite zu implementieren.

In Jetty kann definiert werden, was für Rollen vorhanden sein müssen um eine Operation auszuführen.

@Path("/mitarbeiter")
@RolesAllowed("noser-ma")
public class MitarbeiterResource {

    @GET
    public List<Person> get() {
        return Lists.newArrayList(new Person(1, "Manager CEO"), new Person(2, "Lehrling"));
    }

Dazu wird die Annotation RolesAllowed verwendet. Damit diese Annotation auch innerhalb von Dropwizard funktioniert, wurde ein OpenSource Adapter verwendet.