Liberty での OAuth 2.0 保護リソースの構成

OAuth 2.0 保護リソース・サーバーとして機能するように、Liberty サーバーを構成できます。

このタスクについて

LibertyopenidConnectClient-1.0 フィーチャーを有効にし、他の構成情報に加えて inboundPropagation="required" を設定することによって、OAuth 2.0 保護リソース・サーバーとして機能するように Liberty サーバーを構成できます。OAuth 2.0 リソース・サーバー用の構成は、Liberty での OpenID Connect クライアントの構成と同様です。

OAuth の bearer access_token を保有している当事者であれば、そのトークンを使用して Liberty 内の関連リソースにアクセスできます。Liberty サーバーは、OAuth 2.0 Token Introspection エンドポイント またはOpenID Connect の Userinfo Endpoint のいずれかを呼び出すことによって、OAuth 許可サーバーまたは OpenID Connect プロバイダーに直接照らして、 access_token のリモート検証を行います。

手順

  1. server.xml ファイルに openidConnectClient-1.0Liberty フィーチャーと他の必要なフィーチャーを追加します。 openidConnectClient-1.0 フィーチャーには、ssl-1.0 フィーチャーも必要です。 server.xml ファイルの featureManager エレメントに次のエレメント宣言を追加します。
    <feature>openidConnectClient-1.0</feature> 	
    <feature>ssl-1.0</feature>
  2. openidConnectClient エレメントを構成し、inboundPropagation=”required” を追加することでこのエレメントを OAuth 2.0 保護リソース・サーバーとして有効化します。Liberty サーバーの OpenID Connect プロバイダーおよび OAuth 2.0 許可サーバーで機能する最小構成の例を以下に示します。
    <openidConnectClient id="RS" inboundPropagation="required"		
      clientId="client01" 		
      clientSecret="{xor}LDo8LTor" 		
      validationEndpointUrl="https://server.example.com:443/oidc/endpoint/OP/introspect">		
    </openidConnectClient>
    注: このサンプル構成では、Liberty は OAuth 2.0 Token Introspection を実行します ( validationMethod="introspect" が設定されている)。認証済みサブジェクトは、イントロスペクション・エンドポイントから返される JSON オブジェクトから直接作成され、ユーザー・レジストリーは必要とされません。
    注: Liberty がトークン・イントロスペクションを実行できるようにするためには、Liberty の OAuth 2.0 リソース・サーバーがそれ自体を OAuth クライアントとして OAuth 許可サーバーまたは OpenID Connect プロバイダーに登録する必要があり、トークンのイントロスペクション要求を実行できることが必要です。 clientIdclientSecret は、許可サーバーによって提供されます。
  3. 許可サーバーの署名者証明書を組み込むようにサーバーのトラストストアを構成し、構成されたトラストストアを使用するようにサーバーの SSL 構成を変更します。鍵ストアについては、『Liberty の SSL 通信の使用可能化』を参照してください。

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

  4. オプション:ユーザー・レジストリーを構成します。

    許可サーバーから返されるユーザー ID は、デフォルトではレジストリー・ユーザーにマップされません。そのため、ユーザー・レジストリー内に必要なユーザーはありません。ただし、openidConnectClient エレメントの mapIdentityToRegistryUser 属性が true に設定されている場合は、 認証と許可が成功するためには、許可サーバーから返された該当 ID に対するユーザー・エントリーが存在する必要があります。ユーザー・レジストリーの構成について詳しくは、Liberty のユーザー・レジストリーの構成を参照してください。

  5. オプション: 認証フィルターを構成します。

    openidConnectClient-1.0 フィーチャーが有効で、 openidConnectClient エレメントに authFilterRef 属性が構成されていない場合、非認証の要求試行はすべて、この openidConnectClient エレメントによって認証されます。

    認証フィルターの構成について詳しくは、『認証フィルター』を参照してください。

  6. オプション: 複数の openidConnectClient エレメントおよび複数の認証フィルターを作成することによって、複数の許可サーバーおよび複数の OpenID Connect プロバイダーと連携する OAuth 2.0 リソース・サーバーとして、Liberty を構成できます。各 openidConnectClient エレメントは、 1 つの許可サーバーまたは OpenID Connect プロバイダーとの 1 つの信頼関係を定義し、authFilterRef 属性を使用して 1 つの認証フィルターを参照します。
  7. オプション: validationMethod="userinfo" を設定することによって、OpenID Connect の userinfo endpoint からのユーザー情報を受け取りトークンを検証するように Liberty リソース・サーバーを構成できます。
  8. オプション: Liberty リソース・サーバーは、許可サーバーから受け取った JSON のクレームを使用して認証サブジェクトを作成します。そして、JSON をこのサブジェクトにマップするルールを定義することができます。 『OpenID Connect クライアント』で、userIdentifiergroupIdentifierUserUniqueIdentifierrealmIdentifier、および realmName を参照してください。
  9. オプション: Liberty OAuth 2.0 保護リソース・サーバーは、各要求が有効なアクセス・トークンを提供することを予期していて、認証にシングル・サインオン Cookie を使用することはありません。ただし、authnSessionDisabled="false" を設定することによって、シングル・サインオン Cookie を作成するように Liberty を構成することは可能です。
  10. オプション: JSON をサブジェクトにプログラマチックにマップするために、com.ibm.wsspi.security.oauth.UserCredentialResolver SPI を実装することもできます。

タスクの結果

OAuth 許可サーバーまたは OpenID Connect プロバイダーと通信できる OAuth 2.0 保護リソース・サーバーとして Liberty サーバーを構成するために必要な最小構成を設定しました。

トピックのタイプを示すアイコン タスク・トピック

ファイル名: twlp_config_oauth20_protected_resource.html