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.