Liberty での OpenID Connect プロバイダーの構成

Web シングル・サインオンを利用する OpenID Connect プロバイダー、つまり許可サーバーとして機能するように、Liberty サーバーを構成することができます。

このタスクについて

他の構成情報に加えて、Liberty で openidConnectServer-1.0 フィーチャーを有効にすることによって、OpenID Connect プロバイダーとして機能するように Liberty サーバーを構成できます。

手順

  1. server.xml ファイルに openidConnectServer-1.0 の Liberty フィーチャーと他の必要なフィーチャーを追加します。 openidConnectServer-1.0 フィーチャーには、ssl-1.0 フィーチャーも必要です。
    <feature>openidConnectServer-1.0</feature>
    <feature>ssl-1.0</feature>
  2. OAuth サービス・プロバイダーを定義します。 OpenID Connect は、OAuth 2.0 プロトコルの上に構築されるため、有効な OAuth サービス・プロバイダーを構成する必要があります。 OAuth サービス・プロバイダーの構成には、適切な oauth-rolesoauthProvider、およびユーザー・レジストリーのエレメントが含まれます。 また、OpenID Connect の使用を許可されたユーザーは authenticated oauth-role にマップされる必要があります。 詳しくは、『OAuth サービス・プロバイダーの定義』を参照してください。

    OpenID Connect について OAuth メタデータが更新され、 クライアント・メタデータ内に主な追加があります。 クライアント登録に databaseStore モードを使用する場合は、『クライアント登録要求を受け入れるための OpenID Connect プロバイダーの構成』を参照してください。この文書に従ってクライアントを管理することをお勧めします。 クライアント登録に localStore モードを使用する場合は、 scopepreAuthorizedScopegrantTypesresponseTypesintrospectTokens、 および functionalUserId を他の属性とともに登録できます。

  3. 構成済みの 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 を登録する必要があります。
  4. サポートされる OpenID Connect リライング・パーティー、つまりクライアントの署名者証明書を含むように、サーバーのトラストストアを構成します。 鍵ストアについては、Liberty での SSL 通信の使用可能化を参照してください。
  5. 構成されたトラストストアを使用するように、サーバーの 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 トラストストアにインポートする必要があります。

    注: OpenID Connect を使用するために、scope 属性の有効範囲リストには openid が含まれる必要があります。

    OpenID Connect プロバイダーの構成オプションについては、 OpenID Connect Providerを参照してください。

    その他の OAuth 構成オプションについては、OAuthを参照してください。

  6. [16.0.0.3 以降]オプション: 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 文書を参照してください。

  7. [16.0.0.4 以降]オプション: 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 エンドポイントで戻されるクレームの構成』を参照してください。

タスクの結果

Liberty サーバーを、OpenID Connect クライアントとして構成されている他の Liberty サーバーとの通信が可能な OpenID Connect プロバイダーとして構成するために必要な最小構成が完了しました。

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



タイム・スタンプ・アイコン 最終更新: Tuesday, 6 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twlp_config_oidc_op
ファイル名: twlp_config_oidc_op.html