OpenID Connect の JSON Web Token 認証の構成

JSON Web Token (JWT) トークンをトラステッド認証プロキシー、トラステッド・サービス・クライアント、または OAuth 許可サーバーからの認証トークンとして受け入れるように、 Liberty サーバーを構成することができます。

{
	"iss":"https://idp.acme.com:8020/jwt",
	"sub":"marissa@acme.com",
	"exp":1385066178,
	"aud":"https://resource.acme.com/services",
	"iat":1385062578,
	"groupIds": [
	    "group1", "group2"
	 ]
}

1. openidConnectClient-1.0 Liberty フィーチャーおよびその他の必要なフィーチャーを server.xml ファイルに追加します。 openidConnectClient-1.0 フィーチャーには、最小で transportSecurity-1.0 フィーチャーが必要です。 以下のエレメント宣言を、 server.xml ファイル内の featureManager エレメント内に追加します。

   <feature>openidConnectClient-1.0</feature>
   <feature>transportSecurity-1.0</feature>

2. openidConnectClient エレメントを構成し、 inboundPropagation="required"を設定します。 その他の openidConnectClient 属性については、 OpenID Connect クライアントを参照してください。

   以下のサンプル構成では、JWT トークン発行者が JSON Web Key (JWK) をサポートしており、RS256 アルゴリズムによって署名されていることが想定されています。

   <openidConnectClient id="RS" inboundPropagation="required"
     jwkEndpointUrl="https://acme.com/jwtserver/jwk" signatureAlgorithm="RS256"
     issuerIdentifier="https://idp.acme.com:8020/jwt" >
   </openidConnectClient>

3. Liberty サーバーが JWK エンドポイントへの SSL 接続を確立できるように、JWK エンドポイント証明書を含めるようにトラストストアを構成します。 トラストストアは、 server.xml ファイル内の keyStore エレメントで構成されます。
   このトラストストアを参照するように SSL を構成した後は、その SSL 構成をサーバーのデフォルト SSL 構成として設定するか、openidConnectClient エレメントの sslRef 属性にトラストストア ID を指定することができます。

   JWT 発行者が JWK をサポートしておらず、JWT が代わりに X.509 証明書によって署名されている場合は、発行者の X.509 証明書をトラストストアにインポートします。 openidConnectClient エレメントで、trustStoreRef 属性にトラストストア ID を指定し、trustAliasName 属性で証明書を参照します。

   JWT が、HMAC-SHA256 アルゴリズムを用いる共有秘密鍵を使用して署名されている場合は、clientSecret 属性にその共有秘密鍵を定義します。

   トラストストアまたは鍵ストアについては、 Liberty での SSL 通信の使用可能化を参照してください。

4. openidConnectClient エレメントの issuerIdentifier 属性を、JWT 発行者の iss クレームと一致するように構成します。

   例えば、JWT トークンに "iss":"https://idp.acme.com:8020/jwt" が含まれている場合、issuerIdentifier="https://idp.acme.com:8020/jwt" と設定します。

5. オプション: ユーザー・レジストリーを構成します。
   デフォルトで、JWT をユーザーにマップせずに、検証済み JWT クレームを使用して呼び出し元の認証済みサブジェクトを直接作成するため、ユーザー・レジストリーは必要ありません。

   ただし、openidConnectClient エレメントの mapIdentityToRegistryUser 属性が true に設定されている場合、認証および許可が成功するためには、該当する ID のユーザー・エントリーが許可サーバーから返される必要があります。 ユーザー・レジストリーの構成について詳しくは、 Liberty でのユーザー・レジストリーの構成を参照してください。

6. オプション: 認証フィルターの説明に従って認証フィルターを構成します。

   認証フィルターを構成する場合は、openidConnectClient エレメントの authFilterRef 属性でその認証フィルターを参照します。

   openidConnectClient エレメントが authFilterRef 属性を使用して構成されていない場合、非認証要求試行はこの openidConnectClient エレメントによって認証されます。

7. オプション: 複数の openidConnectClient エレメントおよび複数の認証フィルターを構成して、複数の JWT 発行者または認証プロキシー・サーバーと連携するように Liberty リソース・サーバーを構成します。

   各 openidConnectClient エレメントは、1 つの JWT 発行者または認証プロキシーとの 1 つの信頼関係を定義し、1 つの認証フィルターを参照します。

8. オプション: JWT クレームを認証サブジェクトにマップするためのルールを定義します。
   Liberty リソース・サーバーは、JWT クレームを使用して認証サブジェクトを作成します。以下の openidConnectClient エレメント属性で JWT クレームをサブジェクトにマップする方法を定義できます。

   • userIdentifier
   • userUniqueIdentifier
   • groupIdentifier
   • realmName
   • realmIdentifier

   realmName と realmIdentifier の両方が構成されている場合は、realmName が優先され、realmIdentifier は無視されます。

   クレームとサブジェクトのマッピングを定義しない場合、以下のデフォルト・マッピング・ルールが適用されます。

   • サブジェクト (sub) クレームは、ユーザーのプリンシパル名および固有セキュリティー名として使用される。
   • 発行者 (iss) クレームは、デフォルト・レルムであり、サブジェクト・レルムとして使用される。 JWTトークンに realmName クレームが含まれている場合、 realmName クレームが iss クレームの代わりにサブジェクト・レルムとして使用されます。
9. オプション: シングル・サインオン Cookie を構成します。
   Liberty サーバーは、各要求が有効な JWT トークンを提供することを予期し、認証のためにシングル・サインオン Cookie を作成したり使用したりしません。 シングル・サインオン Cookie を作成するには、openidConnectClient エレメントに authnSessionDisabled="false" を設定します。
10. オプション: JWT トークンを受信するように Liberty サーバーを構成します。 Web クライアントは、以下のいずれかの方法を使用して、リソース要求内の JWT トークンを Liberty リソース・サーバーに送信できます。 JWT トークンが Authorization フィールドまたはフォーム・エンコード本体パラメーターで送信される場合、追加のサーバー構成は必要ありません。
    重要: クライアントは、トークンを送信するために各要求で複数のメソッドを使用してはなりません。 headerName 属性が構成されている場合、Authorization ヘッダー・フィールドまたはフォーム・エンコードされたボディ・パラメーターで送信されるトークンは無視されます。 headerName 属性が構成されていない場合は、Authorization ヘッダーが最初に検索され、その後に access_token パラメーターが検索されます。
    • Authorization 要求ヘッダー・フィールドでトークンを送信する。

      GET /resource HTTP/1.1
      Host: server.example.com
      Authorization: Bearer mF_9.B5f-4.1JqM
      

    • フォーム・エンコードされたボディ・パラメーターとして要求エンティティー本体でトークンを送信する。

      POST /resource HTTP/1.1
      Host: server.example.com
      Content-Type: application/x-www-form-urlencoded
      access_token=mF_9.B5f-4.1JqM
      

    • Libertyでトラステッド・ヘッダー名を構成することにより、カスタマイズされた要求ヘッダー・フィールドでトークンを送信します。

      トラステッド・ヘッダー名を構成するには、 openidConnectClient エレメントに headerName="<myJwtHeaderName>" を設定します。 例えば、headerName="jwt" を設定すると、次の例に示すように、jwt ヘッダー・フィールドでトークンを送信できます。

      GET /resource HTTP/1.1
      Host: server.example.com
      jwt: mF_9.B5f-4.1JqM

11. JWT オーディエンスを構成します。
    信頼できるオーディエンスのリストを定義するには、openidConnectClient エレメントに audiences 属性を構成します。

    有効な JWT トークンは、次のいずれかの条件を満たしている必要があります。

    • audiences 属性が設定されている場合、オーディエンス（ aud ）のクレーム値は、設定されたオーディエンスのいずれかでなければなりません。 オーディエンスチェックを無視するには、 audiences を ALL_AUDIENCES に設定します。
    • audiences 属性が構成されていない場合、JWTトークンに有効な URL である aud クレームが含まれている場合、リソースサービス URL には aud の値をプレフィックスとして設定する必要があります。
      例えば、以下のオーディエンスは、リソースの URL が aud クレーム値で開始されているため有効です。

      • オーディエンス・クレーム: "aud":"https://<server>:<port>/something"
      • リソース URL : https://<server>:<port>/something/specific
      以下のオーディエンスは、リソース URL が aud クレーム値で開始されていないため無効です。

      • オーディエンス・クレーム: "aud":"https://<server>:<port>/something/specific"
      • リソース URL : https://<server>:<port>/something
12. オプション: com.ibm.wsspi.security.oauth.UserCredentialResolver サービス・プログラミング・インターフェース (SPI) を実装して、JWT トークンをサブジェクトにプログラマチックにマップします。

    インターフェースについて詳しくは、「 プログラミング・インターフェース 」の com.ibm.wsspi.security.oauth.UserCredentialResolver SPI 情報、または製品に付属する Java 資料の ${wlp.install.dir}/dev/spi/ibm/ ディレクトリーを参照してください。