Liberty での SAML Web ブラウザー SSO の構成

SAML Web ブラウザー・シングル・サインオン (SSO) サービス・プロバイダーとして機能するように Liberty サーバーを構成できます。

このタスクについて

Liberty サーバーを SAML Web SSO サービス・プロバイダーとして構成するには、他の構成情報に加えて、 Libertyで samlWeb-2.0 フィーチャーを有効にします。

手順

  1. 以下のエレメント宣言を featureManager エレメント内に追加して、 samlWeb-2.0 Liberty フィーチャーを server.xml ファイルに追加します。
    <feature>samlWeb-2.0</feature>
  2. Liberty は、デフォルトの samlWebSso20 エレメントを提供します。
    <samlWebSso20 id="defaultSP">

</samlWebSso20>
    このデフォルト構成では、以下のデフォルト値が想定されています。
    • AssertionConsumerService URL:
      https://<hostname>:<sslport> /ibm/saml20/defaultSP/acs
    • サービス・プロバイダー (SP) メタデータ URL:
      https://<hostname>:<sslport> /ibm/saml20/defaultSP/samlmetadata

      この URL を使用して、このサービス・プロバイダー (SP) のメタデータをブラウザーを使用してダウンロードでき、 この URL を SAML ID プロバイダーに提供して、この SP と ID プロバイダー (IdP) との間の統合を確立できます。

    • IdP メタデータ・ファイルは、サーバー上の resources/security ディレクトリーに idpMetadata.xmlという名前でコピーする必要があります。
    • SAML アサーションの発行者名はセキュリティー・レルムとして使用され、NameID は SAML アサーションから認証済みサブジェクトを作成するためのプリンシパルとして使用されます。
    • KeyStoreRef 属性が指定されていない場合、SAML AuthnRequest は、サーバーのデフォルト鍵ストア内の秘密鍵で署名されます。 keyAlias が構成されていない場合、デフォルトの鍵別名は samlsp です。 keyAlias が構成されておらず、鍵ストアに含まれている秘密鍵が 1 つのみの場合は、その秘密鍵が署名に使用されます。
    注: 新しいサービス・プロバイダー・インスタンスを作成し、 defaultSP が不要になった場合は、 server.xml ファイルに以下を追加して、 defaultSP インスタンスを明示的に無効にする必要があります。
    <samlWebSso20 id="defaultSP" enabled="false">  
</samlWebSso20>
    注: samlWebSso20の ID として、ヌル以外の URL セーフ・ストリングを指定する必要があります。 id が欠落している場合、この構成エレメントは省略され、defaultSP として扱われません。
    注: SAML を構成して有効にすると、すべての非認証要求で SAML 認証が使用されます。 SAML 認証を使用する必要のある要求とその必要のない要求のタイプを構成するには、ステップ 15 の説明に従って認証フィルターを構成する必要があります。
  3. オプション: <samlWebSso20 id="defaultSP"> を server.xml ファイルに追加し、 defaultSP サービス・プロバイダーをカスタマイズすることができます。 以下に例を示します。
    • idpMetadata: IdP メタデータのロケーションとファイル名を、デフォルトのロケーションおよびファイル名 (${server.config.dir}/resources/security/idpMetadata.xml) から変更するには、このパラメーターを追加します。
    • userIdentifier: 値がプリンシパル名として使用される SAML 属性の名前を選択するには、このパラメーターを追加します。
    • groupIdentifier: 値がグループ・メンバーとしてサブジェクトに組み込まれる SAML 属性の名前を選択するには、このパラメーターを追加します。
    • realmName: このサービス・プロバイダー内で SAML プリンシパルを識別するためにレルム名を明示的に指定するには、このパラメーターを使用します。 デフォルトのレルム名は SAML 発行者名です。
  4. オプション: 別の ID で 1 つ以上の新しい samlWebSso20 エレメントを作成できます。 例えば、ID が mySPの新規エレメントを作成する場合、新しい AssertionConsumerService URL を持つ新規 SAML SP インスタンスを効果的に作成します。 
    https://<hostname>:<sslport>/ibm/saml20/mySP/acs
    注: samlWebSso20 用に選択した ID は、 AssertionConsumerService URL およびメタデータ URL を含む SP の URL に含まれます。 samlWebSso20 ID は空であってはならず、URL 用に安全でない文字を含んでいてはなりません。
  5. オプション: トラスト・エンジンを構成できます。 Liberty SAML SP は、以下の 2 つのタイプのトラスト・エンジンをサポートします。
    • メタデータ・トラスト・エンジン: 構成された IdP メタデータ内に指定された情報に照らして署名を検証します。
    • PKIX トラスト・エンジン: 署名内の証明書の信頼性を PKIX 検証を通して検証します。 この検証に合格した証明書は信頼できるものと想定されます。

    デフォルトのトラスト・エンジンはメタデータです。 PKIX トラスト・エンジンを使用したい場合は、PKIXTrustEngine エレメントを追加し、適切な trustAnchor を定義する必要があります。

  6. オプション: SAML から認証済みサブジェクトを作成する方法を構成できます。 デフォルトでは、 Liberty SP は、構成 mapToUserRegistry=Noと同等のローカル・ユーザー・レジストリーを必要とせずに、SAML アサーションから直接サブジェクトを作成します。 その他の構成オプションは、 mapToUserRegistry=User または mapToUserRegistry=Groupです。
    • mapToUserRegistry=No: SAML 発行者の名前がレルムであり、サブジェクト内のプリンシパル名と固有のセキュリティー名を作成するために NameID が使用され、グループ・メンバーは組み込まれません。 属性 userIdentifier、realmIdentifier、groupIdentifier、および userUniqueIdentifier を構成して、カスタマイズされたユーザー名、レルム名、グループ・メンバーシップ、および固有のセキュリティー ID で認証済みサブジェクトを作成することができます。
    • mapToUserRegistry=User: SAML ユーザーをオンプレミス・ユーザー・レジストリーに照らして検証し、ユーザー・サブジェクトをオンプレミス・レジストリーに基づいて作成したい場合は、このオプションを選択します。
    • mapToUserRegistry=Group: SAML グループをローカル・ユーザー・レジストリーに照らして検証し、検証済みのこれらのグループを含むようにサブジェクトを作成したい場合は、このオプションを選択します。 このオプションは、グループ・メンバーシップがオンプレミス・ユーザー・レジストリーに照らして検証されることを除いて、mapToUserRegistry=No に似ています。
  7. オプション: Liberty SAML SPI com.ibm.wsspi.security.saml2.UserCredentialResolver をユーザー・フィーチャーとして実装して、SAML アサーションを Liberty サブジェクトに動的にマップすることができます。
  8. オプション: SP 開始の Web SSO フローを使用する際に、 forceAuthn、 isPassive、 allowCreate、 authnContextClassRef、および authnContextComparisonTypeの 1 つ以上の属性を構成することにより、 IdP にユーザーの認証方法を指示するルールを定義できます。
  9. オプション: nameIDFormat 属性を使用して、必要な NameID 形式を AuthnRequest で定義できます。 SAML 仕様で定義されている任意の NameID フォーマットを指定することも、キーワード customize を使用してカスタム NameId フォーマットを指定することもできます。
  10. オプション: 複数の samlWebSso20 エレメントを作成することで、複数の SP および IdP 連携パートナーを構成できます。各 samlWebSso20 は、1 つの固有の authFilter エレメントを参照します。 すべての authFilters は相互に除外する必要があります。 複数の samlWebSso20 が構成されている場合、それぞれがフェデレーテッド ID プロバイダーでシングル・サインオンを実行でき、独自の認証ポリシーとコンシューム・ルールがあります。
  11. オプション: IdP-initiated unsolicited SSO のサポートを追加します。 Liberty SAML SP は、オンプレミスの IdP メタデータを必要とする場合と必要としない場合に、 IdP開始の非送信請求 SSO をサポートします。 IdP メタデータがない場合、または非送信請求 SSO を使用して 1 つの Liberty SP で複数の ID プロバイダーと統合する場合は、以下の構成を追加する必要があります。
    • <PKIXTrustEngine>を構成し、すべての IdP 署名者証明書を Liberty サーバーのデフォルト・トラストストア、または PKIXTrustEngineの trustAnchor にインポートします。
    • trustedIssuers を構成して、SAML アサーションに含まれる IdP の発行者名をリストします。 発行者名はメタデータ内で EntityID として使用されます。
    • unsolicited SSO のみをサポートしたい場合、 次のステップで説明されているように、SP-initiated unsolicited SSO を構成できます。 このシナリオは、 SAML と関連付けられた SP 内のユーザーのセキュリティー・コンテキストが無効になる場合に役立ちます。 この場合、SP はユーザーを IdP にリダイレクトして戻し、自動的に再び unsolicited SSO を開始できます。
  12. オプション: SP-initiated unsolicited SSO のサポートを追加します。 Liberty SAML SP は、構成済みの IdP メタデータを使用して送信請求 SAML AuthnRequestを実行します。 Liberty SP は、 AuthnRequestを使用せずに、事前構成されたログイン・アプリケーションに非認証要求をリダイレクトすることができます。 このシナリオは、ユーザーが SAML IdPに対して認証を行う前にビジネス・アプリケーションが事前認証処理を実行する場合、または SAML IdP を Liberty SP から非表示にする必要がある場合に役立ちます。 このシナリオを構成するには、 loginPageURL 属性を追加し、その値を、SAML IdPに対する認証をユーザーに指示できる URL に設定します。
  13. オプション: 以下の事項を考慮に入れて、署名要件を構成します。
    • SAML アサーション。 すべての SAML アサーションは SAML IdP によってデジタル署名される必要があります。 署名されていないアサーションを受け入れるという、まれな状況の場合は、明示的に wantAssertionsSigned=false を構成できます。
    • デフォルトの署名アルゴリズムは SHA256 です。 アルゴリズムを変更する必要がある場合、signatureMethodAlgorithm 属性を使用して変更します。
    • SAML AuthnRequest に署名したくない場合、authnRequestsSigned=false と設定できます。
  14. オプション: SP 認証セッションおよび Cookie を構成できます。 SAML アサーションが検証および処理された後、 Liberty SAML SP は、LTPA Cookie を使用せずに、ブラウザーと SP の間の認証済みセッションを維持します。 認証済みセッション・タイムアウトは、 <saml:AuthnStatement> で SessionNotOnOrAfter (指定されている場合)、または server.xml ファイルで構成されている sessionNotOnOrAfter (デフォルトは 120 分) に設定されます。 セッション Cookie 名は自動的に生成されます。属性 spCookieName を使用して目的の名前を指定することにより、Cookie 名をカスタマイズできます。

    Liberty SP が SAML アサーションから LTPA Cookie を作成し、後続の認証要求に LTPA Cookie を使用するようにするには、構成 disableLtpaCookie=falseを追加します。 その LTPA Cookie を他のサーバーと共有したい場合、構成属性 allowCustomCacheKey="false" を追加する必要があります。

    注: disableLtpaCookie="false" および allowCustomCacheKey="false"を構成する場合は、SAML ユーザー名がオンプレミス・ユーザー・レジストリーに対して直接認証されないようにしてください。これにより、ユーザーは 2 つのアカウントを持つことができなくなります。
  15. オプション: 認証フィルターを構成します。

    samlWeb-2.0 フィーチャーが有効になっている場合、すべての非認証要求が 1 つの SAML SP を通して認証されます。 カスタマイズした samlWebSso20 エレメントが定義されている場合、 すべての認証要求がこの samlWebSso20 SP インスタンスによって処理され、そうでない場合はすべての認証がデフォルト・インスタンス defaultSP によって処理されます。 どの SP インスタンスが認証要求を処理するのかを authnFilter を使用して定義できます。

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

  16. オプション: クラスター内で SAML SP を構成します。

    アプリケーション・サーバーがクラスター・メンバーであり、ルーターまたはリバース・プロキシー・サーバーを使用して要求のルーティングを行う場合、以下のタスクを実行する必要があります。

    • ルーターおよびプロキシー・サーバーはセッション・アフィニティーをサポートするように構成される必要があります。
    • 構成属性 spHostAndPort を各アプリケーション・サーバーに追加します。 この属性の値の形式は、(scheme)://(proxyOrRouterHost):(proxyOrRouterPort) です。 例えば、SSL ルーター・エンドポイントは spHostAndPort="https://myRouter.com:443" のように指定でき、非 SSL ルーター・エンドポイントは spHostAndPort="http://myRouter.com:80" のように指定できます。
    • SAML AuthnRequest に署名するための X509 証明書を生成し、この証明書をすべてのアプリケーション・サーバーで使用します。 例えば、 この証明書のみを含む鍵ストアを作成して、すべてのアプリケーション・サーバー上で、この鍵ストアを参照するよう KeyStoreRef を追加します。
    • クラスター環境に createSession="true" が設定されていない場合、ストレス実行中に次のエラーが発生します。
      E CWWKS5029E: The relay state [sp_initial_KGe22fCWKG1lD9VkOMuDz0Ji8pBxFPnU] in the response from the identity provider (IdP) was not recognized.
    以下にクラスター構成の例を示します。
    <keyStore id="samlKeyStore" password="<password>"
              location="${server.config.dir}/resources/security/<samlKey.jks>" />

        <samlWebSso20  id="defaultSP"
               spHostAndPort="https://<IHS host>:<port>"
               keyStoreRef="samlKeyStore"
               createSession="true"
               allowCustomCacheKey="false"
               disableLtpaCookie="false"
               mapToUserRegistry="User">
        </samlWebSso20>
  17. オプション: シングル・ログアウトの SP を構成します。

    Liberty SingleLogoutサービス URL の形式は https://<hostname>:<sslport>/ibm/saml20/<SP configuration ID>/sloで、Liberty SP のメタデータ https://<hostname>:<sslport>/ibm/saml20/<SP configuration ID>/samlmetadataから見つけることができます。

    IdP 開始のシングル・ログアウトの場合、これ以降の構成ステップは不要です。 Liberty SP は SingleLogoutService URL でのログアウト要求を listen し、シングル・ログアウト要求に自動的に応答します。

    Liberty サーバーは、サービス・プロバイダー開始のシングル・ログアウトをサポートしています。 spLogout プロパティーを true に設定すると、SAML シングル・ログアウトを実行するために ibm_security_logout URL および HttpServletRequest.logout() メソッドの両方がアップグレードされます。 このプロパティーを設定するには、 server.xml ファイルで spLogout="true" としてコーディングします。
    <server>
<samlWebSso20 id="sp2" ... spLogout="true" />
...
</server>
    重要: トラブルを回避するために、 https://< hostname>: < sslport> /ibm/saml20/<SP 構成 ID> /samlmetadata エンドポイントを開始して、サービス・プロバイダー・メタデータを再生成してください。

結果

これで、SAML ID プロバイダーによるシングル・サインオンが可能な SAML サービス・プロバイダーとして Liberty サーバーを構成するために必要な構成が確立されました。