Liberty での OpenID Connect クライアントの構成
Web シングル・サインオンを利用し、ID プロバイダーとして OpenID Connect プロバイダーを使用する OpenID Connect クライアント、つまりリライング・パーティーとして機能するように、Liberty サーバーを構成することができます。
このタスクについて
他の構成情報に加えて、Liberty で openidConnectClient-1.0 フィーチャーを有効にすることによって、OpenID Connect クライアントとして機能するように Liberty サーバーを構成できます。
手順
- 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 エレメントを構成します。
以下は、デフォルトの Liberty サーバー OpenID Connect プロバイダーで動作する最小構成の例です。
クライアントには、OpenID Connect プロバイダーからのリダイレクト要求を処理できる構成されたアプリケーションが、指定された URL パターンで使用可能でなければなりません。また、この URL は、クライアント用に OP に登録されたリダイレクト URL に正確に一致する必要があります。
トラブルの回避: アウトバウンド・プロキシーを使用している場合、プロキシー・ホストを介して要求を自動的に転送する手段は OpenID Connect RP では提供されないことに注意してください。OpenID Connect プロバイダー (OP) へのアクセスにプロキシーを使用する必要がある場合は、OP 関連の URL プロパティーに入力する値には、外部 OP のホストおよびポートではなく、プロキシーのホストおよびポートが含まれる必要があります。
ほとんどの場合、OP のホストおよびポートを、プロキシーのホストおよびポートに置き換えることができます。入力する URL は、RP およびクライアント (ブラウザーまたはアプリケーション) の両方に可視でなければなりません。使用する正しい URL を決定する方法について詳しくは、プロキシー管理者にお問い合わせください。
この例では、クライアントは SSL ポートが 443 に設定されると予期しています。
<openidConnectClient id="client01" clientId="client01" clientSecret="{xor}LDo8LTor" authorizationEndpointUrl="https://server.example.com:443/oidc/endpoint/OidcConfigSample/authorize" tokenEndpointUrl="https://server.example.com:443/oidc/endpoint/OidcConfigSample/token"> </openidConnectClient>
このサンプル最小構成では、次のデフォルト値が想定されています。- scope=openid profile: openid の有効範囲は必須です。 scope 属性を使用して必要な有効範囲を編集できます。 例えば、必須の scope を openid profile email に変更できます。
- この RP は、そのリダイレクト URL を OP に https://<host name>:<ssl port>/oidcclient/redirect/client01 として登録します。 ここで、ホスト名と SSL ポートはどちらも自動的に解決され、client01 は openidConnectClient 構成エレメントの ID です。 RP の前にプロキシーがある場合、ホスト名とポートを属性 redirectToRPHostAndPort でオーバーライドし、 redirectToRPHostAndPort を https://<host name>:<ssl port> に設定することができます。
- ユーザー・レジストリーを構成します。OP によって戻されたユーザー ID は、 デフォルトではレジストリー・ユーザーにマップされないため、レジストリーに構成される必要があるユーザーはありません。 ただし、openidConnectClient エレメントの mapIdentityToRegistryUser 属性が true に設定された場合は、 認証と許可が成功するには、OP から戻された該当 ID に対するユーザー・エントリーが存在する必要があります。 ユーザー・レジストリーの構成について詳しくは、Liberty のユーザー・レジストリーの構成を参照してください。
- サポートされる OpenID Connect プロバイダーの署名者証明書を含むように、サーバーのトラストストアを構成します。 鍵ストアについて詳しくは、Liberty での SSL 通信の使用可能化を参照してください。
- 構成されたトラストストアを使用するように、サーバーの SSL 構成を変更します。
<sslDefault sslRef="DefaultSSLSettings" /> <ssl id="DefaultSSLSettings" keyStoreRef="myKeyStore" trustStoreRef="myTrustStore" /> <keyStore id="myKeyStore" password="{xor}EzY9Oi0rJg==" type="jks" location="${server.config.dir}/resources/security/BasicKeyStore.jks" /> <keyStore id="myTrustStore" password="{xor}EzY9Oi0rJg==" type="jks" location="${server.config.dir}/resources/security/BasicTrustStore.jks" />
OpenID Connect は、サーバーで指定されたデフォルト SSL 構成を使用するように構成されます。 そのため、サーバーのデフォルト SSL 構成は、OpenID Connect に構成されたトラストストアを使用する必要があります。
例に示されているように SSL デフォルト構成を使用することに加えて、 sslDefault エレメントで outboundSSLRef 属性を使用して、アウトバウンドのデフォルト SSL 構成を構成できます。アウトバウンド・デフォルト属性が指定されている場合、 outboundSSLRef 属性で指定された SSL 構成がアウトバウンド接続用に使用されます。SSL 構成内でアウトバウンド SSL フィルターを使用することによって、デフォルトをオーバーライドし、アウトバウンド接続に使用するホストとポートを指定することができます。詳しくは、SSL 構成のアウトバウンド・フィルターおよびアウトバウンド通信の SSL 設定の構成を参照してください。
- オプション: サード・パーティーの OpenID Connect プロバイダーを構成します。
サード・パーティーの OpenID Connect プロバイダー (Microsoft Azure や Google など) を使用するように Liberty OpenID Connect クライアントを構成するには、以下の属性の構成が必要です。OP のディスカバリー・エンドポイント (発行者にストリング /.well-known/openid-configuration を連結して形成されるパスの JSON 文書を提供) を呼び出すことで、属性値を入手できます。
- jwkEndpointUrl 属性には、ディスカバリー・ファイルで jwks_uri として定義された、 OP の JSON Web Key Set JWK 文書の URL を設定します。 例えば、Google の OP を使用する場合は、jwkEndpointUrl = "https://www.googleapis.com/oauth2/v2/certs" を設定できます。
- issuerIdentifier 属性には、ディスカバリー・ファイルで定義された issuer を設定します。 iss クレームとしてこの値を含まない ID トークンは、拒否されます。 例えば、Google を OP として使用する場合、issuerIdentifier="accounts.google.com" を設定できます。
- signatureAlgorithm="RS256" を設定します。 Liberty OpenID Connect クライアントのデフォルト署名アルゴリズムは HS256 です。
- userIdentityToCreateSubject 属性には、ユーザーの固有 ID を表すベンダーの ID トークンによって使用されるクレーム名を設定します。 例えば、Google の OP を使用する場合は userIdentityToCreateSubject ="email"、Microsoft Azure を使用する場合は userIdentityToCreateSubject ="upn" または userIdentityToCreateSubject ="unique_name" を設定できます。
- groupIdentifier 属性には、ユーザーのグループ・メンバーシップまたはロールを表すクレーム名を設定します。 例えば、Microsoft Azure を使用する場合、groupIdentifier="groups" を設定できます。
その他の OpenID Connect クライアント構成オプションについては、OpenID Connect Client を参照してください。
- オプション: 認証フィルター。
openidConnectClient-1.0 フィーチャーが有効で、 openidConnectClient エレメントに authFilterRef 属性が構成されていない場合、 非認証要求があれば OpenID Connect プロバイダーで認証されます。
認証フィルターの構成について詳しくは、 認証フィルターを参照してください。
- 複数の OpenID Connect プロバイダーをサポートします。
複数の openidConnectClient エレメントおよび複数の認証フィルターを作成することによって、複数の OpenID Connect プロバイダーへの OpenID Connect リライング・パーティーとして Liberty を構成できます。各 openidConnectClient エレメントは、 1 つの OpenID Connect プロバイダーとの 1 つのシングル・サインオン関係を定義し、authFilterRef 属性を使用して 1 つの認証フィルターを参照します。
- サポートされる ID トークン署名アルゴリズムを構成します。
ID トークンの RS256 署名アルゴリズムをサポートするように Liberty OpenID Connect クライアントを構成できます。Liberty OpenID Connect クライアントのデフォルト署名アルゴリズムは HS256 です。signatureAlgorithm="RS256" を設定することによって、ID トークンの署名アルゴリズムとして RS256 を構成する場合、 OP が JWK エンドポイントをサポートしている場合を除いて、trustStoreRef と trustAliasName の両方を構成する必要があります。
- オプション: 暗黙的な認可タイプを構成します。
openidConnectClient-1.0 フィーチャーは「許可コード」認可タイプを使用してユーザー認証トークンを要求します。 また、server.xml ファイルに grantType="implicit" を追加することによって、暗黙的な認可タイプを使用するように Liberty openidConnectClient-1.0 フィーチャーを構成できます。Liberty サーバーおよび OpenID Connect プロバイダーが別々のファイアウォール内にある場合、この構成オプションを使用する必要があります。
- オプション: Liberty OpenID Connect リライング・パーティーは、ID トークンが処理された後、自動的にシングル・サインオン (SSO) トークンを作成します。 構成プロパティー disableLtpaCookie="true" を追加することで、サーバーの SSO トークンや、OpenID Connect により保護されているリソースの SSO トークンを作成しないように、Liberty を構成できます。 disableLtpaCookie="true" が設定されると、Liberty OpenID Connect クライアントは、構成済みの OpenID Connect プロバイダーで以前に認証されたことのある認証要求のみを受け付けるようになり、認証セッションの存続時間が ID トークンの存続期間に限定されます。
- オプション: 要求を OpenID Connect プロバイダーにリダイレクトしなくても、有効な OAuth 2.0 bearer アクセス・トークンをオプションで認証トークンとして受け入れるように、OpenID Connect クライアントを構成できます。 要求に有効な OAuth 2.0 bearer アクセス・トークンが含まれている場合、Liberty OpenID Connect クライアントは自動的にそのアクセス・トークンを検証し、トークン検証結果に基づいて認証済みサブジェクトを作成します。要求にアクセス・トークンが含まれていないか、またはアクセス・トークンが無効である場合、Liberty OpenID Connect クライアントは引き続きユーザーを OpenID Connect プロバイダーにリダイレクトします。この機能により、Liberty サーバーは、RESTful クライアントのように、ブラウザー・クライアントとしても非ブラウザー・クライアントとしても機能するようになります。inboundPropagation=”supported” を構成に追加することで、この機能を有効にできます。
ホスティング環境で /oidcclient コンテキスト・ルートへのアクセスが許可されない場合は、oidcClientWebapp エレメントを構成してコンテキスト・ルートを変更してください。
デフォルトで、Liberty OpenID Connect クライアントのリダイレクト・サーブレットは /oidcclient コンテキスト・ルートで listen し、そのリダイレクト URL フォーマットは https://<host_name>:<ssl_port>/oidcclient/redirect/<configuration_ID> です。このコンテキスト・ルートを使用できない場合は、サーバー構成に別のコンテキスト・ルートを設定してください。
例えば、ホスティング環境で /acme/openid コンテキスト・ルートの使用が必要な場合は、次のエレメントを追加します。<oidcClientWebapp contextPath="/acme/openid" />
結果のリダイレクト URL フォーマットは https://<host_name>:<ssl_port>/acme/openid/redirect/<configuration_ID> になります。
タスクの結果
サブトピック
- OpenID Connect の認可エンドポイントの起動
OpenID Connect では、認可エンドポイントがユーザーの認証および認可を扱います。 - OpenID Connect のイントロスペクション・エンドポイントの起動
イントロスペクション・エンドポイントにより、アクセス・トークン保有者は、 アクセス・トークンに関するメタデータのセットをそのアクセス・トークンを発行した OpenID Connect プロバイダーから要求することができます。アクセス・トークンは、OpenID Connect または OAuth 認証を介して取得されたものでなければなりません。 OpenID Connect の失効エンドポイントの起動
失効エンドポイントにより、アクセス・トークンまたはリフレッシュ・トークンの保有者から OpenID Connect プロバイダーに、発行されたトークンは不要になったため失効させられる必要があることを通知できます。失効エンドポイントは、OpenID Connect または OAuth 認証を介して取得されたトークンを失効させることができます。OpenID Connect のログアウト・エンドポイントの起動
クライアントは、ログアウト・エンドポイントを使用して、Web ブラウザーのプロバイダー側セッションおよび Cookie をクリアします。- OpenID Connect のセッション管理エンドポイントの起動
セッション管理エンドポイントは、OpenID Connect リライング・パーティーが特定の OpenID Connect プロバイダー (OP) でのユーザーのログイン状況をモニターするのを可能にし、 その際のネットワーク・トラフィックを最小化します。セッション管理エンドポイントを利用することによって、 リライング・パーティー (RP) は、OpenID Connect プロバイダーからログアウトしたユーザーをログアウトすることができます。 - OpenID Connect のトークン・エンドポイントの起動
OpenID Connect Authorization Code Flow では、ID トークン、アクセス・トークン、およびリフレッシュ・トークンを取得するために、 クライアントによってトークン・エンドポイントが使用されます。 - OpenID Connect の UserInfo エンドポイントの起動
UserInfo エンドポイントは、OpenID Connect 認証で認証されたユーザーについてのクレームを返します。

ファイル名: twlp_config_oidc_rp.html