JSON Web トークン (JWT)

JSON Web トークン (JWT) は、JSON オブジェクトとしてフォーマットされた認証情報を安全に送信するために使用されます。

JWT は発行者によってデジタル署名されるため、パスワードを Db2®に公開することなく、署名を検証することで認証目的で使用できます。 JWT 内のクレームは、ユーザーの ID Db2を識別します。

一般には、アプリケーションを介してユーザーがログインするときに JWT を生成するのは ID プロバイダー (IDP) 製品です。ただし、個々のアプリケーション自体で JWT を作成することも可能です。 Db2 は JWT を検証できますが、JWT を生成する方法は提供しません。

JWT ワークフローのダイアグラム

JWT の発行者は、トークンの「iss」クレームに指定する必要があります。 JWT の署名を検証するための鍵を見つけるには、トークン構成ファイル (db2token.cfg) の JWT_IDP_ISSUER パラメーターに、完全に一致する発行者が指定されていなければなりません。 鍵の保持にはタイプ PKCS#12 のローカル鍵ストア・ファイル (*.p12) が使用されます。このファイルの場所を、トークン構成ファイルに構成しておく必要があります。

署名アルゴリズムは、JWT ヘッダーの一部として宣言されます。 Db2 は、以下の署名アルゴリズムをサポートしています。
  • SHA2 を使用する HMAC (HS256、HS384、HS512)
  • SHA2 を使用する RSASSA-PKCS1-v1 (RS256、RS384、RS512)
  • SHA256 を使用する ECDSA P-256 (ES256)
  • SHA384 を使用する ECDSA P-384 (ES384)
  • SHA512 を使用する ECDSA P-512 (ES512)
  • Db2 バージョン 11.5.5以降で使用可能:
    • SHA-256 と MGF1 + SHA-256 を使用した RSASSA-PSS (PS256)
    • SHA-384 と MGF1 + SHA-384 を使用した RSASSA-PSS (PS384)
    • SHA-512 と MGF1 + SHA-512 を使用した RSASSA-PSS (PS512)

Db2 は、暗号化された JWT をサポートしません。 ネットワーク経由で送信された JWT を保護するには、TLS/SSL を使用することを強くお勧めします。

Db2 が、示されたアルゴリズムで署名されたトークンを検証するには、適切な鍵を構成する必要があります。 HS256、HS384、または HS512 を使用する場合は、JWT の署名に使用された秘密鍵を構成する必要があります。 RSA 署名アルゴリズムごとに、適切な公開鍵が含まれている証明書を構成する必要があります。 これらの鍵のラベルは、db2token.cfg ファイルで指定します。

トークン・ホルダーの ID を判別するために、 Db2 はトークン自体の内容を調べます。 トークン内のどのクレームにユーザー ID が入っているかは、トークン構成ファイルの JWT_IDP_AUTHID_CLAIM パラメーターで判別します。 このクレームは、 Db2内のユーザーの許可 ID と見なされます。 必須ではありませんが、このクレームには「sub」 (サブジェクト) または「username」という名前がよく付けられます。 多くの場合、個々の IDP は、生成する JWT をカスタマイズする機能を持っているので、「db2authid」などのクレームを生成することもできます。

許可 ID クレームで指定された値に対しては、何の処理も実行されません。 例えば、E メール・アドレスが指定されたクレームが、ユーザー名とドメインの部分に分けられることはありません。そのまま全体が保持されます。

Db2 はメソッドの取り消しをサポートしていないため、JWT の「exp」クレームに有効期限時刻を含める必要があります。 有効期限時刻として適切な値を慎重に決定する必要があります。 JWT が悪意のあるユーザーの手に渡った場合、値が大きすぎると、使用可能な時間が長くなります。 値が小さすぎると、 Db2 操作を妨害する可能性があります。 いったん接続が確立されると、トークンの有効期限が切れても影響はありません。 ただし、トークンが再利用される可能性がある状況もいくつかあり、その場合にトークンの有効期限が切れていると、処理が正常に実行されません。 異なるのは、主に次の点です。
  • 自動クライアント・リルート: 新規接続を再確立するときに、既存のトークンが再使用されます。有効期限が切れている場合は失敗します。
  • リモート・データ・ソースへのフェデレーション接続: シングル・サインオン (SSO) が構成されている場合は、リモート・データ・ソースへのアウトバウンド接続に、フェデレーション・サーバーへの接続に使用された JWT が使用されます。 トークンの有効期限が切れている場合、この接続は失敗します。

JWT が生成されると、多くの場合、リフレッシュ・トークンも生成されます。 Db2 は、有効期限が切れていない新しい JWT を取得するためのリフレッシュ・トークンの使用をサポートしていません。

Db2 は、JWT からグループ情報やその他の許可の詳細を取得しません。 ユーザーのグループの取得には、標準のグループ・プラグインが使用されます。

JWT を Db2 で検証するには、以下のプロパティーが必要です。

  • 「typ」クレームがトークン・ヘッダーに存在する場合には、値 JWT が必要です。 クレームはオプションであり、必須ではありません。
  • サポートされるアルゴリズムの「alg」クレーム、および db2token.cfg ファイルに鍵が適切に構成されていること
  • db2token.cfg ファイル内の発行者と一致する「iss」クレーム。
  • ユーザーの許可 ID を指定する JWT_IDP_AUTHID_CLAIM クレーム。
  • 有効期限が切れていない値が指定された「exp」クレーム。

JWT には他のクレームを含めることができますが、 Db2はそれらのクレームを無視します。

JWT ヘッダーとクレームの例を以下に示します。

ヘッダーの例:
{
   "alg": "RS256",
   "typ": "JWT"
}
ペイロードの例:
{
   "username": "admin",
   "sub": "admin",
   "iss": "KNOXSSO",
   "aud": "DSX",
   "role": "Admin",
   "permissions": [
     "administrator",
     "can_provision"
   ],
   "uid": "1000330999",
   "authenticator": "default",
   "display_name": "admin",
   "iat": 1579286619,
   "exp": 1579329819
 }
この例の説明
  • 発行者は KNOXSSO です。
  • JWT の署名アルゴリズムは RS256 (SHA256 を使用する RSA 署名) を使用しています。
  • JWT の有効期間は 12 時間に設定されています。
  • 「Username」クレームは、 Db2 許可 ID を識別します。