Liberty での SAML Web ブラウザー SSO の構成
SAML Web ブラウザー・シングル・サインオン (SSO) サービス・プロバイダーとして機能するように Liberty サーバーを構成できます。
このタスクについて
他の構成情報に加えて、Liberty で samlWeb-2.0 フィーチャーを有効にすることによって、SAML Web SSO サービス・プロバイダーとして機能するように Liberty サーバーを構成できます。
手順
- featureManager エレメントの内側に次のエレメント宣言を追加することによって、
server.xml ファイルに samlWeb-2.0 Liberty フィーチャーを追加します。
<feature>samlWeb-2.0</feature>
- 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 の説明に従って認証フィルターを構成する必要があります。 - AssertionConsumerService
URL:
- オプション: server.xml ファイルに <samlWebSso20 id="defaultSP"> を追加し、
defaultSP サービス・プロバイダーをカスタマイズすることができます。以下に例を示します。
- idpMetadata: IdP メタデータのロケーションとファイル名を、デフォルトのロケーションおよびファイル名 (${server.config.dir}/resources/security/idpMetadata.xml) から変更するには、このパラメーターを追加します。
- userIdentifier: 値がプリンシパル名として使用される SAML 属性の名前を選択するには、このパラメーターを追加します。
- groupIdentifier: 値がグループ・メンバーとしてサブジェクトに組み込まれる SAML 属性の名前を選択するには、このパラメーターを追加します。
- realmName: このサービス・プロバイダー内で SAML プリンシパルを識別するためにレルム名を明示的に指定するには、このパラメーターを使用します。デフォルトのレルム名は SAML 発行者名です。
- オプション: 異なる ID で 1 つ以上の新規 samlWebSso20 エレメントを作成できます。例えば、
mySP という ID で新規エレメントを作成することで、
次のような新しい AssertionConsumerService URL を持つ新規 SAML SP インスタンスを実際的に作成できます。
https://<hostname>:<sslport>/ibm/saml20/mySP/acs
注: samlWebSso20 用に選択する ID は、 AssertionConsumerService URL とメタデータ URL を含めて、SP の URL に組み込まれます。samlWebSso20 ID は空であってはならず、URL 用に安全でない文字を含んでいてはなりません。 - オプション: トラスト・エンジンを構成できます。Liberty SAML SP は、次の 2 種類のトラスト・エンジンをサポートします。
- メタデータ・トラスト・エンジン: 構成された IdP メタデータ内に指定された情報に照らして署名を検証します。
- PKIX トラスト・エンジン: 署名内の証明書の信頼性を PKIX 検証を通して検証します。この検証に合格した証明書は信頼できるものと想定されます。
デフォルトのトラスト・エンジンはメタデータです。PKIX トラスト・エンジンを使用したい場合は、PKIXTrustEngine エレメントを追加し、適切な trustAnchor を定義する必要があります。
- オプション: SAML から認証済みサブジェクトを作成する方法を構成できます。デフォルトでは、Liberty SP は、ローカル・ユーザー・レジストリーを必要とせずに、SAML アサーションからサブジェクトを直接作成します。これは構成 mapToUserRegistry=No と等価です。他の構成オプションには mapToUserRegistry=User と mapToUserRegistry=Group があります。
- mapToUserRegistry=No: SAML 発行者の名前がレルムであり、サブジェクト内のプリンシパル名と固有のセキュリティー名を作成するために NameID が使用され、グループ・メンバーは組み込まれません。属性 userIdentifier、realmIdentifier、groupIdentifier、および userUniqueIdentifier を構成して、カスタマイズされたユーザー名、レルム名、グループ・メンバーシップ、および固有のセキュリティー ID で認証済みサブジェクトを作成することができます。
- mapToUserRegistry=User: SAML ユーザーをオンプレミス・ユーザー・レジストリーに照らして検証し、ユーザー・サブジェクトをオンプレミス・レジストリーに基づいて作成したい場合は、このオプションを選択します。
- mapToUserRegistry=Group: SAML グループをローカル・ユーザー・レジストリーに照らして検証し、検証済みのこれらのグループを含むようにサブジェクトを作成したい場合は、このオプションを選択します。このオプションは、グループ・メンバーシップがオンプレミス・ユーザー・レジストリーに照らして検証されることを除いて、mapToUserRegistry=No に似ています。
- オプション: Liberty SAML SPI、com.ibm.wsspi.security.saml2.UserCredentialResolver をユーザー・フィーチャーとして実装して、SAML アサーションを Liberty サブジェクトに動的にマップすることができます。
- オプション: SP-initiated Web SSO フローを使用している場合、属性 forceAuthn、isPassive、allowCreate、authnContextClassRef、 および authnContextComparisonType のうちの 1 つ以上を構成することによって、ユーザーを認証する方法を IdP に通知するためのルールを定義できます。
- オプション: AuthnRequest 内の必要な NameID フォーマットを nameIDFormat 属性を使用して定義できます。 SAML 仕様に定義されているいずれかの NameID フォーマットを指定するか、または、キーワード customize を使用してカスタム NameId フォーマットを指定することができます。
- オプション: 複数の samlWebSso20 エレメントを作成し、各 samlWebSso20 が 1 つの固有の authFilter エレメントを参照するようにすることで、複数の SP と IdP の統合パートナーを構成できます。 すべての authFilter が互いに排他的でなければなりません。複数の samlWebSso20 が構成されていると、 それぞれが独自の統合された ID プロバイダーでのシングル・サインオンを実行でき、それぞれが独自の認証ポリシーとコンシューム・ルールを持ちます。
- オプション: IdP-initiated unsolicited SSO のサポートを追加します。
Liberty SAML SP は、IdP-initiated unsolicited SSO を、オンプレミスの IdP メタデータを必要とするものと必要としないものの両方ともサポートします。IdP メタデータがない場合、
または、1 つの Liberty SP と複数の ID プロバイダーの統合を unsolicited SSO を使用して行うつもりである場合、以下の構成を追加する必要があります。
- <PKIXTrustEngine> を構成し、すべての IdP 署名者証明書を、Liberty サーバーのデフォルトのトラストストアか、PKIXTrustEngine の trustAnchor にインポートします。
- trustedIssuers を構成して、SAML アサーションに含まれる IdP の発行者名をリストします。発行者名はメタデータ内で EntityID として使用されます。
- unsolicited SSO のみをサポートしたい場合、 次のステップで説明されているように、SP-initiated unsolicited SSO を構成できます。このシナリオは、 SAML と関連付けられた SP 内のユーザーのセキュリティー・コンテキストが無効になる場合に役立ちます。 この場合、SP はユーザーを IdP にリダイレクトして戻し、自動的に再び unsolicited SSO を開始できます。
- オプション: SP-initiated unsolicited SSO のサポートを追加します。 Liberty SAML SP は、構成された IdP メタデータを使用して、solicited SAML AuthnRequest を実行します。Liberty SP は AuthnRequest を使用せずに、事前構成済みログイン・アプリケーションに非認証要求をリダイレクトすることが可能です。このシナリオは、 ビジネス・アプリケーションが事前認証処理を実行した後でないとユーザーが SAML IdP への認証を行えない場合、 または、SAML IdP が Liberty SP から隠される必要がある場合に有用です。このシナリオを構成するには、loginPageURL 属性を追加し、 その値を、ユーザーに SAML IdP への認証を指示することのできる URL に設定します。
- オプション: 以下の事項を考慮に入れて、署名要件を構成します。
- SAML アサーション。すべての SAML アサーションは SAML IdP によってデジタル署名される必要があります。署名されていないアサーションを受け入れるという、まれな状況の場合は、明示的に wantAssertionsSigned=false を構成できます。
- デフォルトの署名アルゴリズムは SHA256 です。アルゴリズムを変更する必要がある場合、signatureMethodAlgorithm 属性を使用して変更します。
- SAML AuthnRequest に署名したくない場合、authnRequestsSigned=false と設定できます。
- オプション: 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 ユーザー名が直接認証しないことを確認してください。 - オプション: 認証フィルターを構成します。
samlWeb-2.0 フィーチャーが有効になっている場合、すべての非認証要求が 1 つの SAML SP を通して認証されます。カスタマイズした samlWebSso20 エレメントが定義されている場合、 すべての認証要求がこの samlWebSso20 SP インスタンスによって処理され、そうでない場合はすべての認証がデフォルト・インスタンス defaultSP によって処理されます。どの SP インスタンスが認証要求を処理するのかを authnFilter を使用して定義できます。
認証フィルターの構成について詳しくは、『認証フィルター』を参照してください。
- オプション: クラスター内で SAML SP を構成します。
アプリケーション・サーバーがクラスター・メンバーであり、ルーターまたはリバース・プロキシー・サーバーを使用して要求のルーティングを行う場合、以下のタスクを実行する必要があります。
- ルーターおよびプロキシー・サーバーはセッション・アフィニティーをサポートするように構成される必要があります。
- 各アプリケーション・サーバーに構成属性 spHostAndPort を追加し、その値をルーターまたはプロキシー・サーバーのホスト名とポートに設定します。例えば、 spHostAndPort="https://myRouter.com:443" です。
- 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>
タスクの結果


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-libcore-mp&topic=twlp_config_saml_web_sso
ファイル名: twlp_config_saml_web_sso.html