Liberty での OpenID Connect プロバイダーの構成
Web シングル・サインオンを利用する OpenID Connect プロバイダー、つまり許可サーバーとして機能するように、Liberty サーバーを構成することができます。
このタスクについて
他の構成情報に加えて、Liberty で openidConnectServer-1.0 フィーチャーを有効にすることによって、OpenID Connect プロバイダーとして機能するように Liberty サーバーを構成できます。
手順
- server.xml ファイルに openidConnectServer-1.0 の Liberty
フィーチャーと他の必要なフィーチャーを追加します。
openidConnectServer-1.0 フィーチャーには、ssl-1.0 フィーチャーも必要です。
<feature>openidConnectServer-1.0</feature> <feature>ssl-1.0</feature>
- OAuth サービス・プロバイダーを定義します。
OpenID Connect は、OAuth 2.0 プロトコルの上に構築されるため、有効な OAuth サービス・プロバイダーを構成する必要があります。
OAuth サービス・プロバイダーの構成には、適切な
oauth-roles、oauthProvider、およびユーザー・レジストリーのエレメントが含まれます。
また、OpenID Connect の使用を許可されたユーザーは authenticated oauth-role にマップされる必要があります。
詳しくは、『OAuth サービス・プロバイダーの定義』を参照してください。
OpenID Connect について OAuth メタデータが更新され、 クライアント・メタデータ内に主な追加があります。 クライアント登録に databaseStore モードを使用する場合は、『クライアント登録要求を受け入れるための OpenID Connect プロバイダーの構成』を参照してください。この文書に従ってクライアントを管理することをお勧めします。 クライアント登録に localStore モードを使用する場合は、 scope、preAuthorizedScope、grantTypes、responseTypes、introspectTokens、 および functionalUserId を他の属性とともに登録できます。
- 構成済みの oauthProvider を参照する oauthProviderRef 属性を含む openidConnectProvider エレメントを追加します。
各 oauthProvider を参照できるのは、1 つの openidConnectProvider のみです。
2 つ以上の openidConnectProvider エレメントが同じ oauthProvider を参照することはできません。
client エレメントの name 属性と secret 属性は、
対応する OpenID Connect クライアントの client ID および client secret に一致しなければなりません。
以下の例は、デフォルトの Liberty サーバー OpenID Connect クライアントで動作します。 注: この例で、OP はクライアントの SSL ポートが 443 に設定されることを想定しています。
<openidConnectProvider id="OidcConfigSample" oauthProviderRef="OAuthConfigSample" /> <oauthProvider id="OAuthConfigSample"> <localStore> <client name="client01" secret="{xor}LDo8LTor" displayname="client01" scope="openid profile email" redirect="https://server.example.com:443/oidcclient/redirect/client01"/> </localStore> </oauthProvider>
注: 有効な client で、authorization_code 付与タイプについてその name、redirect、scope、および secret を登録する必要があります。 - サポートされる OpenID Connect リライング・パーティー、つまりクライアントの署名者証明書を含むように、サーバーのトラストストアを構成します。 鍵ストアについては、Liberty での SSL 通信の使用可能化を参照してください。
- 構成されたトラストストアを使用するように、サーバーの SSL 構成を変更します。
<sslDefault sslRef="DefaultSSLSettings" /> <ssl id="DefaultSSLSettings" keyStoreRef="myKeyStore" trustStoreRef="myTrustStore" /> <keyStore id="myKeyStore" password="{xor}Lz4sLCgwLTs=" type="jks" location="${server.config.dir}/resources/security/BasicKeyStore.jks" /> <keyStore id="myTrustStore" password="{xor}Lz4sLCgwLTs=" type="jks" location="${server.config.dir}/resources/security/BasicTrustStore.jks" />
OpenID Connect は、サーバーで指定されたデフォルト SSL 構成を使用するように構成されます。 そのため、サーバーのデフォルト SSL 構成は、OpenID Connect に構成されたトラストストアを使用する必要があります。
OpenID Connect のユーザー同意フォームはプラグ可能で、これにより、プロバイダーが独自の同意フォームを作成して保守することができます。 このフォームは SSL で取得されるため、同意フォームがホストされるサーバーの署名者証明書を含むようにトラストストアを構成する必要があります。 デフォルトの同意フォームが使用され、OpenID Connect に使用されるトラストストアが、Liberty サーバーで使用される鍵ストアと異なるように構成された場合、Liberty サーバーの署名者証明書を OpenID Connect トラストストアにインポートする必要があります。
例に示されているように SSL デフォルト構成を使用することに加えて、 sslDefault エレメントで outboundSSLRef 属性を使用して、アウトバウンドのデフォルト SSL 構成を構成できます。アウトバウンド・デフォルト属性が指定されている場合、 outboundSSLRef 属性で指定された SSL 構成がアウトバウンド接続用に使用されます。SSL 構成内でアウトバウンド SSL フィルターを使用することによって、デフォルトをオーバーライドし、アウトバウンド接続に使用するホストとポートを指定することができます。詳しくは、SSL 構成のアウトバウンド・フィルターおよびアウトバウンド通信の SSL 設定の構成を参照してください。
注: OpenID Connect を使用するために、scope 属性の有効範囲リストには openid が含まれる必要があります。その他の OpenID Connect プロバイダー構成オプションについては、OpenID Connect Provider を参照してください。
その他の OAuth 構成オプションについては、Oauth を参照してください。
オプション: JSON Web Token (JWT) トークンを access_token トークンとして発行するように Liberty OpenID Connect プロバイダーを構成します。
デフォルトでは、Liberty は不透明な access_token トークンを発行します。不透明なトークンでは、トークン受信者がトークンを発行したサーバーにコールバックすることが必要とされます。oauthProvider 構成エレメントに jwtAccessToken="true" を設定するか、com.ibm.wsspi.security.oauth20.JwtAccessTokenMediator サービス・プログラミング・インターフェース (SPI) を実装することにより、トークン内にトークン検証メカニズムを組み込む access_token トークンとして JWT トークンを代わりに発行するように Liberty OpenID Connect プロバイダーを構成することができます。
このインターフェースについて詳しくは、『WebSphere OAuth 2.0 Web シングル・サインオン SPI』、または ${wlp.install.dir}/dev/spi/ibm/ ディレクトリー内にある、製品と共に提供されている Java 文書を参照してください。
オプション: Liberty OpenID Connect プロバイダーが送信する id_token トークンのコンテンツをカスタマイズします。
デフォルトで、Liberty OpenID Connect プロバイダーは、ユーザー名とグループ・メンバーシップ情報を含む id_token トークンを発行します。このトークンのコンテンツは、以下の方法でカスタマイズできます。- com.ibm.wsspi.security.openidconnect.IDTokenMediator SPI を実装して、id_token のコンテンツを完全にカスタマイズします。SPI では最大限の柔軟性が提供されるため、ユーザーは独自のカスタム・トークンを作成できます。
このインターフェースについて詳しくは、『WebSphere OAuth 2.0 Web シングル・サインオン SPI』、または ${wlp.install.dir}/dev/spi/ibm/ ディレクトリー内にある、製品と共に提供されている Java 文書を参照してください。
- サーバー構成内の openidConnectProvider エレメントの customClaims 属性に追加のクレームをリストすることにより、Federated User Registry から追加のユーザー属性をフェッチします。クレーム名が Federated User Registry 内の属性名と異なる場合は、クレーム名を claimToUserRegistryMap エレメントの属性にマップします。例えば、以下の構成は、複数のクレームを追加し、alias クレームを seeAlso レジストリー属性にマップし、lastName クレームを sn 属性にマップします。
<openidConnectProvider id="MyOP" oauthProviderRef="MyOauth" customClaims= "alias, email, lastName, employeeType, office"> <claimToUserRegistryMap alias="seeAlso" lastName="sn"/> ... </openidConnectProvider>
詳しくは、UserInfo エンドポイントで戻されるクレームの構成を参照してください。
- com.ibm.wsspi.security.openidconnect.IDTokenMediator SPI を実装して、id_token のコンテンツを完全にカスタマイズします。SPI では最大限の柔軟性が提供されるため、ユーザーは独自のカスタム・トークンを作成できます。
オプション: ユーザーが自分のソーシャル・メディア・アカウントでログインできるようにするため、 ユーザー認証をソーシャル・ログインに委任するように Liberty OpenID Connect プロバイダーを構成します。
ソーシャル・ログインが Liberty OpenID Connect プロバイダーに対して構成されている場合、ユーザーは、Liberty プロバイダー用にアカウントを作成する必要はなく、 自分のソーシャル・メディア・アカウントを使用してログインすることができます。詳しくは、『Liberty でのソーシャル・ログインの構成』を参照してください。
- オプション:
クライアント・リダイレクト URL (Uniform Resource Locator) 内で正規表現を使用するように Liberty OpenID Connect プロバイダーを構成します。
- 正規表現の使用を有効にするには、allowRegexpRedirects クライアント属性を true に設定します。
- URL を正規表現として評価するように、regexp: ストリングに接頭部を追加します。 正規表現のない URL が最初に検査されます。
- 登録エンドポイントを通してクライアントを登録するときには、正規表現に含まれる円記号 (¥) を感嘆符 (!) に置き換えてください。
注: 意図しない URL へのリダイレクトの許可は機密漏れになる可能性があります。正規表現を使用する場合は、許可したくない URL に一致することがないよう注意してください。次の例では、https://apphost043.example.com URL は正規表現に一致するため、この URL へのリダイレクトが許容されます。
<openidConnectProvider id="OidcConfigSample" oauthProviderRef="OAuthConfigSample" /> <oauthProvider id="OAuthConfigSample"> <localStore> <client name="client01" secret="{xor}LDo8LTor" displayname="client01" scope="openid profile email" allowRegexpRedirects="true"> <redirect>"https://apphost.example.com:443/oidcclient/redirect/client01"</redirect> <redirect>"regexp:https://apphost\d\d\d\.example\.com:443/oidcclient/redirect/client01"</redirect> </client> </localStore> </oauthProvider>
タスクの結果
サブトピック
- OAuth 2.0 許可サーバーとしての OpenID Connect プロバイダーの使用
OpenID Connect プロバイダーは、通常の OAuth 2.0 許可プロバイダーとして使用して、OAuth 2.0 access_token を発行すること、およびすべての OAuth 2.0 許可タイプのサポートすることが可能です。 - ディスカバリー要求を受け入れるための OpenID Connect プロバイダーの構成
ディスカバリー構成エンドポイントは、OpenID Connect プロバイダー (OP) サーバーによってサポートされる機能に関する情報を使用可能にします。 - UserInfo エンドポイントで戻されるクレームの構成
UserInfo エンドポイントによって戻されたクレームをカスタマイズするように Liberty OpenID Connect プロバイダーを構成することができます。 - 2-legged OAuth 要求を使用可能にするための OpenID Connect プロバイダーの構成
標準的な OAuth フローは 3 つの「leg」(クライアントと認可サーバーとの間の対話のステージ) からなります。 leg が 2 つの (2-legged) OAuth シナリオでは、ユーザーとの対話が不要になるようにクライアントは事前認可済みのスコープを使用するので、 標準的なフローの leg のうちの 1 つは実行不要になります。具体的には、認可サーバーへの認証も、 要求されたスコープによって指定される情報を共有することへの同意も必要ありません。代わりに、すべての要求されたスコープ・パラメーターは事前認可済みであると見なされ、 自動的に要求トークンに追加されます。その後、この要求トークンが認可サーバーに送信されます。 - ID トークンの署名に RSA-SHA256 アルゴリズムを使用するための OpenID Connect プロバイダーの構成
ID トークンの署名に RS256 アルゴリズムを使用するように OpenID Connect プロバイダーを構成することができます。 - 許可付与の JSON Web Token (JWT) を受け入れるための OpenID Connect プロバイダーの構成
アクセス・トークンの代わりに JSON Web Token を受け入れる OpenID Connect プロバイダーとして機能する Liberty サーバーを構成することができます。 - クライアント登録要求を受け入れるための OpenID Connect プロバイダーの構成
クライアント登録エンドポイントは、OpenID Connect プロバイダーを使用しようとする OpenID Connect リライング・パーティーに関する情報を登録、更新、削除、取得するための管理者の管理対象サービスです。 代わりに、登録プロセスは、リライング・パーティーがそれを使用するための情報 (OAuth 2.0 クライアント ID やクライアント秘密鍵など) を未指定の場合に提供できます。 - OpenID Connect カスタム・フォーム
ユーザー認証用のデフォルト・フォーム・ログイン・ページを置き換えたり、クライアント許可データを収集するための独自のユーザー同意フォームを開発したりすることができます。 - ユーザーの認証
OpenID Connect プロバイダーでは、ユーザー認証に従来型の Java™ Platform, Enterprise Edition (J2EE) FormLogin がサポートされます。

ファイル名: twlp_config_oidc_op.html