© Excellent backgrounds/Shutterstock.com
Java Magazin
Kolumne: EnterpriseTales

Autorisierung mit dem JSON Web Token in Enterprise Java

Authentifizierung mit dem JSON Web Token ist mittlerweile State of the Art in verteilten Systemlandschaften. Aber wie sieht es beim Thema Autorisierung aus? Diese Kolumne wirft einen Blick darauf, wie und in welchem Umfang Autorisierung mit dem JSON Web Token in Spring (Boot) und MicroProfile möglich ist und wo es Grenzen gibt.

Arne Limburg


Der Prozess der Authentifizierung ist auch in verteilten Anwendungen mittlerweile weitestgehend standardisiert. In modernen Systemen werden Verfahren wie OpenID Connect und OAuth 2 verwendet. Als Austauschformat für die Authentifizierungsinformationen kommt in der Regel das JSON Web Token (JWT) zum Einsatz. Wie aber sieht es mit den Autorisierungsinformationen aus?Standardisierte Informationen im JWTDabei kann ein JWT theoretisch beliebige Informationen enthalten, allerdings gibt es einige Standardinformationen (Claims), die enthalten sein sollten, wie Subject (sub), Issuer (iss) und Expiration Time (exp) [1].Autorisierung in verteilten ArchitekturenIn einer verteilten Systemlandschaft stellt sich bei der Wahl der Benutzergruppen zunächst die Frage, ob diese Gruppen global für alle Services gültig sind oder ob es spezifische Benutzergruppen gibt, die nur für bestimmte Services relevant sind. Häufig findet man eine Mischung aus beiden Situationen. Es gibt immer Benutzergruppen, die für alle Services relevant sind, aber auch solche, die nur für einzelne Services gelten. Mindestens für die globalen Benutzergruppen ist es sinnvoll, wenn sie zentral verwaltet werden. Ein existierender Authentication Server bietet sich hierfür geradezu an. Wie bereits erwähnt, ist es möglich, im JSON Web Token beliebige Informationen zu hinterlegen. Wenn die Verwaltung der Benutzergruppen also im Authentication Server passiert, ist es sinnvoll, diese Informationen in den ausgestellten Tokens zu hinterlegen. Der Applikationsserver kann sie von dort auslesen und für die Zugriffskontrolle verwenden. Zur Erinnerung: Der Authentication Server signiert das Token, sodass der Applikationsserver sicher sein kann, dass die Gruppeninformationen auch tatsächlich von dort kommen und nicht etwa vom Benutzer selbst hinzugefügt wurden.Leider gibt es im JWT-Standard keine Definition, in welcher Form (also in welchem Claim) die Gruppeninformationen hinterlegt werden können. Wenn ein Authentication Server diese Informationen also im Token hinterlegen will, ist ihm freigestellt, wie er das tut. Listing 1 zeigt exemplarisch die Repräsentation, die der Keycloak-Server standardmäßig wählt. Durch das Beispiel wird bereits das Problem mit Autorisierung in verteilten Anwendungen deutlich: Da ein Standard für das Hinterlegen der Benutzergruppen fehlt, muss jeder Service, der diese Informationen nutzen will, an die Struktur des jeweiligen Authentication Servers angepasst werden. Ein Wechsel des Authenti...

Java Magazin
Kolumne: EnterpriseTales

Autorisierung mit dem JSON Web Token in Enterprise Java

Authentifizierung mit dem JSON Web Token ist mittlerweile State of the Art in verteilten Systemlandschaften. Aber wie sieht es beim Thema Autorisierung aus? Diese Kolumne wirft einen Blick darauf, wie und in welchem Umfang Autorisierung mit dem JSON Web Token in Spring (Boot) und MicroProfile möglich ist und wo es Grenzen gibt.

Arne Limburg


Der Prozess der Authentifizierung ist auch in verteilten Anwendungen mittlerweile weitestgehend standardisiert. In modernen Systemen werden Verfahren wie OpenID Connect und OAuth 2 verwendet. Als Austauschformat für die Authentifizierungsinformationen kommt in der Regel das JSON Web Token (JWT) zum Einsatz. Wie aber sieht es mit den Autorisierungsinformationen aus?Standardisierte Informationen im JWTDabei kann ein JWT theoretisch beliebige Informationen enthalten, allerdings gibt es einige Standardinformationen (Claims), die enthalten sein sollten, wie Subject (sub), Issuer (iss) und Expiration Time (exp) [1].Autorisierung in verteilten ArchitekturenIn einer verteilten Systemlandschaft stellt sich bei der Wahl der Benutzergruppen zunächst die Frage, ob diese Gruppen global für alle Services gültig sind oder ob es spezifische Benutzergruppen gibt, die nur für bestimmte Services relevant sind. Häufig findet man eine Mischung aus beiden Situationen. Es gibt immer Benutzergruppen, die für alle Services relevant sind, aber auch solche, die nur für einzelne Services gelten. Mindestens für die globalen Benutzergruppen ist es sinnvoll, wenn sie zentral verwaltet werden. Ein existierender Authentication Server bietet sich hierfür geradezu an. Wie bereits erwähnt, ist es möglich, im JSON Web Token beliebige Informationen zu hinterlegen. Wenn die Verwaltung der Benutzergruppen also im Authentication Server passiert, ist es sinnvoll, diese Informationen in den ausgestellten Tokens zu hinterlegen. Der Applikationsserver kann sie von dort auslesen und für die Zugriffskontrolle verwenden. Zur Erinnerung: Der Authentication Server signiert das Token, sodass der Applikationsserver sicher sein kann, dass die Gruppeninformationen auch tatsächlich von dort kommen und nicht etwa vom Benutzer selbst hinzugefügt wurden.Leider gibt es im JWT-Standard keine Definition, in welcher Form (also in welchem Claim) die Gruppeninformationen hinterlegt werden können. Wenn ein Authentication Server diese Informationen also im Token hinterlegen will, ist ihm freigestellt, wie er das tut. Listing 1 zeigt exemplarisch die Repräsentation, die der Keycloak-Server standardmäßig wählt. Durch das Beispiel wird bereits das Problem mit Autorisierung in verteilten Anwendungen deutlich: Da ein Standard für das Hinterlegen der Benutzergruppen fehlt, muss jeder Service, der diese Informationen nutzen will, an die Struktur des jeweiligen Authentication Servers angepasst werden. Ein Wechsel des Authenti...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang