Teil 26: Open Source und IBM i – JSON Web Token

Das Thema Sicherheit wird immer wichtiger und wird auch in Zukunft sämtliche Systeme vor neue Herausforderungen stellen. In diesem Teil möchte Ich Ihnen zeigen, was JSON Web Token sind und wie Sie damit in kürzester Zeit Ihre IBM i Web- und Microservices zusätzlich absichern können.

Nutzen werden wir für die Implementierung IceBreak.
Selbstverständlich ist eine Entwicklung auch ohne IceBreak möglich, z.B. mit Keycloak oder dem IceBreak Subframework ILEastic, welches als Open Source Projekt frei verfügbar ist. Dies würde jedoch im Vergleich ein Vielfaches an Mehraufwand bedeuten und, da es Ihnen vermutlich genauso geht wie mir, ist Zeit eben genau das, wovon wir immer zu wenig haben.

Ein weiterer wichtiger Aspekt, gerade wenn es um Sicherheit geht, ist, dass wir im Idealfall sämtliche Implementierungen auf der IBM i behalten, um somit das mögliche Potential für Sicherheitslücken von Drittanbietern möglichst bei null zu halten.
Hier ist IceBreak als einziger nativer Web- und Application-Server natürlich die erste Wahl.

 

Was ist ein JSON Web Token?

Widmen wir uns zunächst der Frage Was ist ein JSON Web Token?

Sofern Sie nicht wissen, um was es sich bei JSON handelt (Javascript Object Notation), schauen Sie bitte im Verzeichnis des TechKnowLetters nach. Hier finden sich einige Artikel zu dem Thema, u.a. von Markus A. Litters innerhalb dieser Open Source Serie.

Salopp gesagt, ein JSON Web Token (JWT) ist wie eine Eintrittskarte zu einem Event oder Festival. Nur eben ausgestellt von Ihrer IBM i: für eben Ihre Aufgaben bzw. Zugänge, welche zu verschiedensten Zwecken genutzt werden können.

In der Praxis werden JWT in Verbindung mit Webservices und Microservices genutzt und dienen der Absicherung eben dieser.

Der eigentliche Inhalt des JWT ist hier in der Tat beliebig. Ob Nutzerinformationen, Berechtigungseinstellungen oder jegliche Art sonstiger Daten, das JWT ist hier völlig offen und kann entsprechend Ihrer Bedürfnisse angepasst und erweitert werden. Sämtliche Daten werden in dem sogenannten „Payload“-Teil des JWT gespeichert.

Technisch betrachtet ist ein JWT ein offener Standard (RFC 7519), der eine kompakte und in sich geschlossene Methode für die sichere Übertragung von Informationen zwischen Parteien in Form eines JSON-Objekts definiert. Diese Informationen können überprüft und als vertrauenswürdig eingestuft werden, da sie digital signiert sind.

JWTs können mit einem geheimen (mit dem HMAC-Algorithmus) oder einem öffentlichen/privaten Schlüsselpaar mit RSA oder ECDSA signiert werden.

In Ihrer kompaktesten Form bestehen JSON-Web-Token aus drei Teilen, die durch Punkte voneinander getrennt sind. Diese Teile sind:

• Header (Kopfzeile)
• Payload (Nutzlast)
• Signature (Signatur)

Entsprechend sieht ein JWT normalerweise wie folgt aus:

xxxxx.yyyyy.zzzzz

Schauen wir uns die verschiedenen Teile an…

 

Header

Der Header – zu Deutsch Kopfzeile – besteht in der Regel aus zwei Teilen: dem Typ des Tokens, d.h. JWT, und dem verwendeten Signieralgorithmus, z. B. HMAC SHA256 oder RSA.

Zum Beispiel:

{

„alg“: „HS256“,

„typ“: „JWT“

}

Anschließend wird dieses JSON in Base64Url kodiert und bildet den ersten Teil des JWT.

 

Payload

Der zweite Teil des Tokens ist der Payload bzw. die Nutzlast, die die sogenannten Claims enthält. Claims sind Aussagen über eine Entität (in der Regel den Nutzer) und zusätzliche Daten. Es gibt drei Arten von Claims: registrierte, öffentliche und private Claims.

 

Registrierte Claims

Hierbei handelt es sich um eine Reihe von vordefinierten Angaben, die nicht Pflicht sind, aber empfohlen werden, um eine Reihe nützlicher, auch systemübergreifender Angaben bereitzustellen. Einige von ihnen sind:

• iss (Aussteller)
• exp (Verfallszeit)
• sub (Subjekt)
• aud (Empfänger)
• und weitere

Beachten Sie, dass die Claim-Namen nur drei Zeichen lang sind, da ein JWT möglichst kompakt sein soll.

Beispiele:

• iss (issuer): Aussteller des JWT
• sub (subject): Subjekt/Gegenstand des JWT (der Benutzer)
• aud (audience): Empfänger, für den das JWT bestimmt ist
• exp (expiration time): Zeit, nach der das JWT abläuft
• nbf (not before time): Zeitpunkt, vor dem das JWT nicht zur Verarbeitung angenommen werden darf
• iat (issued at time): Zeitpunkt, zu dem das JWT ausgestellt wurde; kann verwendet werden, um das Alter des JWT zu bestimmen
• jti (JWT ID): Eindeutiger Bezeichner; kann verwendet werden, um zu verhindern, dass das JWT wiederholt wird (ein Token kann nur einmal verwendet werden)

 

Öffentliche Claims (Public Claims)

Diese können von den Nutzern von JWTs nach Belieben definiert werden. Um Kollisionen zu vermeiden, sollten sie jedoch in der IANA JSON Web Token Registry definiert werden oder als URI definiert werden, die einen kollisionssicheren Namensraum enthält.

Beispiele:

Hier geht’s zur vollständigen IANA JSON Web Token Registry

 

Private Claims

Dies sind benutzerdefinierte Angaben, die erstellt werden, um Informationen zwischen Parteien auszutauschen, die sich auf ihre Verwendung einigen, und die weder registriert noch öffentlich sind.

Beispiel:

Ein Beispiel für eine Nutzlast könnte sein:

{

„sub“: „1234567890“,

„name“: „John Doe“,

„admin“: true

}

Der Payload wird dann mit Base64Url kodiert und bildet den zweiten Teil des JSON Web Tokens.

Beachten Sie, dass diese Informationen bei signierten Tokens zwar gegen Manipulationen geschützt sind, aber dennoch von jedermann gelesen werden können. Geben Sie keine geheimen Informationen in die Payload- oder Header-Elemente eines JWTs ein, es sei denn, sie sind verschlüsselt.

 

Signature (Signatur)

Um den Signaturteil zu erstellen, müssen Sie den verschlüsselten Header, den verschlüsselten Payload, ein Secret (Passwort) und den im Header angegebenen Algorithmus nehmen und diesen signieren.

Wenn Sie zum Beispiel den HMAC SHA256 Algorithmus verwenden wollen, wird die Signatur wie folgt erstellt:

HMACSHA256(

base64UrlEncode(header) + „.“ +

base64UrlEncode(payload),

secret)

Die Signatur wird verwendet, um zu überprüfen, ob die Nachricht unterwegs verändert wurde. Im Falle von Tokens, die mit einem privaten Schlüssel signiert wurden, kann damit auch überprüft werden, ob der Absender des JWT derjenige ist, der er zu sein vorgibt.

 

Alles zusammen

Die Ausgabe sind drei durch Punkte getrennte Base64-URL-Strings, die problemlos in HTML- und HTTP-Umgebungen weitergegeben werden können und im Vergleich zu XML-basierten Standards wie SAML kompakter sind.

Die folgende Abbildung zeigt ein JWT, bei dem der vorherige Header und die Nutzdaten kodiert und mit einem Secret signiert sind.

Direkt gegenübergestellt sieht das Ganze so aus:

Zur Veranschaulichung habe Ich hier den Editor der Seite jwt.io verwendet. Hier können Online JWTs encodiert bzw. decodiert werden, um diese zu veranschaulichen.

Im nächsten Teil widmen wir uns der Funktionsweise von JSON Web Tokens und der konkreten Anwendungsmöglichkeiten für Ihr Unternehmen.

Ihr Markus Glaser

 

Markus Glaser ist Anwendungsentwickler für IBM i bei edv.beratung.litters.

Er schreibt regelmäßig für den TechKnowLetter. 

Der TechKnowLetter erscheint monatlich. Sechs Ausgaben erhalten Sie für 88 Euro hier.