Liberty での SAML Web インバウンド伝搬の構成

HTTP ヘッダーの SAML トークンを認証トークンとして受け入れるように Liberty サーバーを構成できます。この機能は通常、認証済みユーザーの代わりに SAML を使用するプロキシーまたは RESTful クライアントで使用します。

このタスクについて

Liberty で samlWeb-2.0 フィーチャーを有効にし、他の構成情報に加えて inboundPropagation=required を設定することで、HTTP ヘッダーの SAML トークンを認証トークンとして受け入れるように Liberty サーバーを構成できます。インバウンド伝搬の構成は、『Liberty での SAML Web ブラウザー SSO の構成』と似ています。

手順

  1. featureManager エレメントの内側に次のエレメント宣言を追加することによって、 server.xml ファイルに samlWeb-2.0 Liberty フィーチャーを追加します。
    <feature>samlWeb-2.0</feature>
  2. SAML インバウンド伝搬を有効にします。Liberty にはデフォルトの samlWebSso20 エレメントがあります。
    <samlWebSso20 id="defaultSP">
    
    </samlWebSso20>
    このデフォルトの samlWebSso20 エレメントを使用できます。あるいは、新規 samlWebSso20 エレメントを作成して、inboundPropagation=required を追加することで、SAML インバウンド伝搬を有効にすることができます。
    <samlWebSso20 id="defaultSP" inboundPropagation="required" >
    </samlWebSso20>
    注: SAML が構成され使用可能にされると、すべての非認証要求が SAML 認証を使用するようになります。SAML 認証を使用できる要求と使用できない要求のタイプを構成するには、このトピックの説明に従って認証フィルターを構成する必要があります。
  3. PKIX 検証を介して署名内の証明書の信頼性を検証するように PKIX トラスト・エンジンを構成する必要があります。この検証に合格した証明書は信頼できるものと想定されます。
    1. <PKIXTrustEngine> を構成し、すべてのトラステッド SAML 署名者証明書を、Liberty サーバーのデフォルトのトラストストアか、PKIXTrustEnginetrustAnchor にインポートします。
    2. オプション: 証明書の信頼性が不十分な場合に SAML アサーションに含まれる SAML トークンの発行者名をリストするため、trustedIssuers を構成します。
    以下の例は、サンプル構成です。
    <samlWebSso20 id="defaultSP"          
      inboundPropagation="required"
      headerName="saml_token"
      signatureMethodAlgorithm="SHA1">
      <pkixTrustEngine trustAnchor="serverStore" />
    </samlWebSso20>  
  4. オプション: headerName を追加して、SAML トークンが含まれる HTTP 要求ヘッダー名を定義できます。この構成属性が定義されていない場合、Liberty サーバーは、SAML トークンとしてヘッダー名 samlSaml、および SAML を検索します。HTTP 要求の SAML トークン・ヘッダーは、次のいずれかのフォーマットにすることができます。
    Authorization=[<headerName>=<SAML_HERE>]                  
    Authorization=[<headerName>="<SAML_HERE>"] 
    Authorization=[<headerName> <SAML_HERE>]
    <headerName>=[<SAML_HERE>]

    SAML トークンは、Base-64 または UTF-8 エンコードでなければならず、GZIP フォーマットで圧縮できます。

    注: この SAML トークン・ヘッダー名は、URL セーフのストリングでなければならず、先行空白文字および末尾空白文字が含まれていてはなりません。
  5. オプション: SAML から認証済みサブジェクトを作成する方法を構成できます。デフォルトでは、Liberty サービス・プロバイダーは、ローカル・ユーザー・レジストリーを必要とせずに、SAML アサーションからサブジェクトを直接作成します。これは構成 mapToUserRegistry=No と等価です。他の構成オプションには mapToUserRegistry=UsermapToUserRegistry=Group があります。
    • mapToUserRegistry=No: SAML 発行者の名前は realm であり、サブジェクト内のプリンシパル名と固有のセキュリティー名を作成するために NameID が使用され、グループ・メンバーは組み込まれません。属性 userIdentifierrealmIdentifiergroupIdentifier、および userUniqueIdentifier を構成して、カスタマイズされたユーザー名、レルム名、グループ・メンバーシップ、および固有のセキュリティー ID で認証済みサブジェクトを作成することができます。
    • mapToUserRegistry=User: SAML ユーザーをローカル・ユーザー・レジストリーに照らして検証し、ユーザー・サブジェクトをローカル・ユーザー・レジストリーに基づいて作成したい場合は、このオプションを選択します。
    • mapToUserRegistry=Group: SAML グループをローカル・ユーザー・レジストリーに照らして検証し、検証済みのこれらのグループを含むようにサブジェクトを作成したい場合は、このオプションを選択します。このオプションは、グループ・メンバーシップがローカル・ユーザー・レジストリーに照らして検証されることを除いて、mapToUserRegistry=No に似ています。
  6. オプション: Liberty SAML SPI、com.ibm.wsspi.security.saml2.UserCredentialResolver をユーザー・フィーチャーとして実装して、SAML アサーションを Liberty サブジェクトに動的にマップすることができます。
  7. オプション: 複数の samlWebSso20 エレメントを構成し、各 samlWebSso20 エレメントが 1 つの固有の authFilter エレメントを参照するようにすることができます。 すべての authFilter エレメントが互いに排他的でなければなりません。複数の samlWebSso20 エレメントが構成されている場合、各エレメントが独自の認証ポリシーおよびコンシューム・ルールを持ちます。
  8. オプション: 以下の事項を考慮に入れて、署名要件を構成します。

    デフォルトの署名アルゴリズムは SHA256 です。アルゴリズムを変更する必要がある場合、signatureMethodAlgorithm 属性を使用して変更します。

  9. オプション: 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" を構成する場合、 1 人のユーザーが 2 つのアカウントを持つことを防止するローカル・ユーザー・レジストリーに SAML ユーザー名が直接認証しないことを確認してください。
  10. 認証フィルターを構成します。authnFilter を使用して、インバウンド伝搬認証要求を処理する samlWebSso20 エレメントを定義できます。

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

タスクの結果

これで、SAML トークンを使用して HTTP 要求を認証するように Liberty サーバーを構成するために必要な構成が設定されました。

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



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