OAuth 2.0 保護リソース・サーバーとして機能するように、Liberty サーバーを構成できます。
このタスクについて
Liberty で openidConnectClient-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 のリモート検証を行います。
手順
- server.xml ファイルに openidConnectClient-1.0 の Liberty
フィーチャーと他の必要なフィーチャーを追加します。
openidConnectClient-1.0 フィーチャーには、ssl-1.0 フィーチャーも必要です。
server.xml ファイルの featureManager エレメントに次のエレメント宣言を追加します。
<feature>openidConnectClient-1.0</feature>
<feature>ssl-1.0</feature>
- 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 プロバイダーに登録する必要があり、トークンのイントロスペクション要求を実行できることが必要です。
clientId と
clientSecret は、許可サーバーによって提供されます。
- 許可サーバーの署名者証明書を組み込むようにサーバーのトラストストアを構成し、構成されたトラストストアを使用するようにサーバーの SSL 構成を変更します。鍵ストアについては、『Liberty の SSL 通信の使用可能化』を参照してください。
鍵ストアについては、Liberty の SSL 通信の使用可能化を参照してください。
- オプション:ユーザー・レジストリーを構成します。
許可サーバーから返されるユーザー ID は、デフォルトではレジストリー・ユーザーにマップされません。そのため、ユーザー・レジストリー内に必要なユーザーはありません。ただし、openidConnectClient エレメントの mapIdentityToRegistryUser 属性が true に設定されている場合は、
認証と許可が成功するためには、許可サーバーから返された該当 ID に対するユーザー・エントリーが存在する必要があります。ユーザー・レジストリーの構成について詳しくは、Liberty のユーザー・レジストリーの構成を参照してください。
- オプション: 認証フィルターを構成します。
openidConnectClient-1.0 フィーチャーが有効で、
openidConnectClient エレメントに authFilterRef 属性が構成されていない場合、非認証の要求試行はすべて、この openidConnectClient エレメントによって認証されます。
認証フィルターの構成について詳しくは、『認証フィルター』を参照してください。
- オプション: 複数の openidConnectClient エレメントおよび複数の認証フィルターを作成することによって、複数の許可サーバーおよび複数の OpenID Connect プロバイダーと連携する OAuth 2.0 リソース・サーバーとして、Liberty を構成できます。各 openidConnectClient エレメントは、
1 つの許可サーバーまたは OpenID Connect プロバイダーとの 1 つの信頼関係を定義し、authFilterRef 属性を使用して 1 つの認証フィルターを参照します。
- オプション: validationMethod="userinfo" を設定することによって、OpenID Connect の userinfo endpoint からのユーザー情報を受け取りトークンを検証するように Liberty リソース・サーバーを構成できます。
- オプション: Liberty リソース・サーバーは、許可サーバーから受け取った JSON のクレームを使用して認証サブジェクトを作成します。そして、JSON をこのサブジェクトにマップするルールを定義することができます。
『OpenID Connect クライアント』で、userIdentifier、groupIdentifier、UserUniqueIdentifier、realmIdentifier、および realmName を参照してください。
- オプション: Liberty OAuth 2.0 保護リソース・サーバーは、各要求が有効なアクセス・トークンを提供することを予期していて、認証にシングル・サインオン Cookie を使用することはありません。ただし、authnSessionDisabled="false" を設定することによって、シングル・サインオン Cookie を作成するように Liberty を構成することは可能です。
- オプション: JSON をサブジェクトにプログラマチックにマップするために、com.ibm.wsspi.security.oauth.UserCredentialResolver SPI を実装することもできます。
タスクの結果
OAuth 許可サーバーまたは OpenID Connect プロバイダーと通信できる OAuth 2.0 保護リソース・サーバーとして Liberty サーバーを構成するために必要な最小構成を設定しました。