ご覧のページは、お客様の利便性のために一部機械翻訳されています。また、ドキュメントは頻繁に更新が加えられており、翻訳は未完成の部分が含まれることをご了承ください。最新情報は都度公開されておりますため、必ず英語版をご参照ください。翻訳に問題がある場合は、こちらまでご連絡ください。

SAML Authentication Process Overview

変更通知を受け取る（購読する）

IDプロバイダーとサービスプロバイダーの両方がシングルサインオンプロセスを開始できますが、SSOフローはそれぞれによって異なります。 SSOは開始方法に関わらず、SPとIdP間の通信はHTTPSで構成されているため、トランスポート層のすべての通信は暗号化されます。 SAML リクエストは、Liferay で構成された証明書を使用して署名され、 SAML 2.0 仕様で定義されている SAML Web Browser SSO プロファイルを使用します。レスポンスは常に HTTP-POST または HTTP-Redirect を使用して送信されます。 HTTP-POST が推奨されます。これは、URL が長すぎてブラウザが処理できないリスクを軽減するためです。

IDプロバイダー主導のSSO

ユーザーがブラウザから直接IdPにリクエストを送信することで、SSOサイクルに入る場合がある。

IDプロバイダー主導のSSOは直接認証を行います。

IdPへのSSOリクエスト

LiferayがIdPの場合、IdPが開始したSSO URL：

パスは /c/portal/saml/sso のように指定する必要があります。
以前に構成されたサービスプロバイダ接続 (SPC) の識別子である entityId パラメータを含める必要があります。
認証が成功した際にユーザーがリダイレクトされるURLエンコードされた値を含む RelayState パラメーターが含まれる場合があります。このURLは、希望するSPC上の場所を指す必要がある（SAML 2.0標準のセクション3.4.3によると、この値は長さが80バイトを超えてはならない）。 SSO実行後にランディングページを指定しておくと便利です。

Liferay以外のIdP（Siteminder、ADFSなど）を使用する場合は、IdPが開始するSSO URLの構築方法について、ベンダーのドキュメントを参照してください。

IDプロバイダーがユーザーが認証されていないと判断した場合、適切なログイン画面をユーザーに表示します。

IdPからのSSO応答

認証が成功すると、IdPはSAMLレスポンスを作成します。これには、指定されたサービスプロバイダ接続 (SPC) で構成された属性ステートメントが含まれます (Liferay の SAML アダプタで SPC を設定する方法については、インスタンスレベルでの SAML の構成を参照してください)。

IdPは、応答をアサーションコンシューマーサービスURLに送信します。リクエストには、 SAMLResponse と RelayState の 2 つのパラメータが含まれています。

注

SAMLレスポンスの送信方法（例えばHTTP-POST）とアサーションコンシューマーサービスURLは、通常、SPが提供するSAMLメタデータXMLの一部としてインポートされます。 Liferay DXPでは、SAMLアダプタの「サービスプロバイダ接続」タブでSPのメタデータをインポートします。

SPはSSO応答を処理する

SPはSAMLレスポンスを検証し、処理します。 Liferay の SAML ソリューションでは、署名付きの SAMLResponse メッセージが必要です。この署名プロセスにより、IDプロバイダーの適切な識別が保証され、SAMLレスポンスのなりすましが防止されます。

一方のLiferayインスタンスがIdPで、もう一方がSPである場合、SPにインポートされるSAMLメタデータXMLファイルにIdPの証明書が含まれていることを確認してください。
LiferayがIdPで、別のアプリケーションがSPである場合は、IdPから証明書をエクスポートし、SPの証明書ストアにインポートします。

SAML レスポンスに RelayState が含まれている場合、ユーザーはその場所にリダイレクトされます。それ以外の場合は、サービスプロバイダのホームページが表示されます。

サービスプロバイダー主導のシングルサインオン（SSO）

ほとんどの場合、認証要求はサービスプロバイダから送信されます。

サービスプロバイダー主導のSSOは、認証要求の一般的な発生源です。

SPへのSSOリクエスト

ユーザーのブラウザがSP上の保護されたリソースまたはログインURLを要求すると、SPが開始するSSOプロセスがトリガーされます。 Liferay DXP が SAML SP の場合、SSO は /c/portal/login URL を要求するか、認証が必要な保護されたリソース (たとえば、ゲストロールでは表示できないドキュメント) を要求することによって開始されます。ユーザーが保護されたリソースを要求した場合、その URL は RelayState パラメーターに記録されます。ユーザーが /c/portal/loginを要求した場合、 RelayState は redirect パラメータを指定することで設定できます。それ以外の場合、ポータルプロパティ auth.forward.by.last.path が trueに設定されている場合、最後にアクセスされたパスが RelayState として設定されます。 Liferay以外のサービスプロバイダーの場合は、SSOの開始方法についてベンダーのドキュメントを参照してください。

IdPへの認証リクエスト

SP は IdP のシングルサインオンサービス URL を検索し、 AuthnRequest を送信します。 LiferayがSPの場合、構成済みのSAMLアイデンティティプロバイダー接続を検索し、SAMLメタデータXMLドキュメントで定義されているIdPのシングルサインオンサービスURLにSAML AuthnRequest を送信します。 Liferay は、HTTP-POST または HTTP-Redirect バインディングを使用して AuthnRequest を送受信することをサポートしています。 HTTP POSTが推奨されます。

ユーザーにアクティブなセッションがない場合、または ForceAuthn が SP によって要求された場合、ユーザーは資格情報を提供して認証する必要があります。 LiferayがIDプロバイダー（IdP）である場合、認証はログインポートレットで行われます。 Liferay は、ユーザーに認証を要求する前に、 AuthnRequest をデコードして検証します。

注

ForceAuthn オプションを設定するには、 グローバルメニュー () を開き、 コントロールパネル → SAML 管理 → ID プロバイダー接続の詳細 に移動します。

IdPからのSSO応答

認証後、SAMLレスポンスが作成され、SPのAssertion Consumer Service URLに送信され、検証されます。 IdPはSPメタデータに基づいてこの選択を自動的に行います。

LiferayがIdPとして構成されている場合、サービスプロバイダー接続で構成された属性はすべて、属性ステートメントとしてレスポンスに含まれます。アサーションコンシューマーサービスのURLは、SPのSAMLメタデータXMLから取得されます。

LiferayがSPとして構成されている場合、レスポンスとアサーションの署名が検証されます。 Liferayでは、送信者が認証されている必要があります。これは、発行元のIDプロバイダーによるメッセージ全体の署名によって行われます。署名のない応答は認証されていないとみなされ、拒否されます。 Liferay以外のSPまたはIdPベンダーについては、各ベンダーのドキュメントを参照してください。

ユーザーは、要求されたリソース、または RelayState パラメーターに含まれる URL (たとえば、SSO を開始する前にユーザーが最後にアクセスしたページ) にリダイレクトされます。

シングルログアウト

シングルログアウト（SLO）リクエストは、ユーザーのブラウザからIdPまたはSPに送信され、SLOフローはそれぞれの場合で異なります。まず、IdPが開始するSLOについて考えてみましょう。

IDプロバイダー主導のSLO

IDプロバイダー主導のSLOは、ユーザーのブラウザによってIDプロバイダーに直接送信されます。

IdPへのSLOリクエスト

IdPが開始するSLOリクエストは、ユーザーのブラウザによってIdPに直接送信されます。 LiferayがIdPの場合、IdPが開始するSSO URLはURLパスを次のように指定する必要があります。

/c/portal/logout

ユーザーが設定済みのいずれかのサービスプロバイダ（SP）にサインオンしている場合、SAMLがログアウト処理を引き継ぎ、サインオンしているすべてのサービスを表示します。単一のログアウト画面には、各SPの認証ステータスと、ログアウトできないSPがあるかどうか（たとえば、SPがダウンしている場合やSLOをサポートしていない場合など）が表示されます。 Liferay以外のIdP（Siteminder、ADFSなど）を使用する場合は、IdPが開始するSLO URLの構築方法について、ベンダーのドキュメントを参照してください。

IdP は SAML LogoutRequest を SP に送信します。

Liferay が IdP として構成されている場合、 LogoutRequest は HTTP-POST、HTTP-Redirect、または SOAP バインディングを使用して送信されます。 HTTP-POSTバインディングが推奨されますが、それが利用できない場合は、バインディングをサポートする最初のSLOエンドポイントが選択されます。
Liferay が SP として構成されている場合、 LogoutRequest でサポートされているバインディングは、HTTP-Post、HTTP-Redirect、または SOAP です。
その他のIDプロバイダー（IdP）またはサービスプロバイダー（SP）については、各ベンダーのドキュメントを参照してください。

SPからのSLO応答

SP は IdP に LogoutResponse を送信します。

IdP は SAML LogoutRequest を 2 番目の SP に送信します。

次に、2 番目の SP は LogoutResponse を IdP に送信します。このプロセスは、ユーザーがログインしているすべてのサービスプロバイダ（SP）に対して繰り返されます。 Liferay が IdP の場合、最後の SP が LogoutResponse を配信するか、タイムアウトになった後に、Liferay はユーザーをログアウトします。

サービスプロバイダー主導のSLO

サービスプロバイダー主導のSLOは、ユーザーのブラウザがSPにログアウト要求を送信したときに発生します。

SPへのSLOリクエスト

SP主導のSLOでは、ユーザーのブラウザがログアウト要求をSPに直接送信します。 LiferayがSPとして構成されている場合、SLOは、このログアウトURLを要求することによって開始されます。

/c/portal/logout

その他のサービスプロバイダーについては、SLOの開始に関するベンダーのドキュメントを参照してください。

SAML LogoutRequest が IdP のシングルログアウトサービス URL に送信されます。

Liferay が SP として機能する場合、 LogoutRequest は、SAML プロバイダーの IdP 接続タブで構成された IdP (IdP 接続の設定については、 Liferay を ID プロバイダーとして設定するを参照) と、SAML メタデータで定義された SLO サービス URL に送信されます。
LiferayがIdPの場合、ユーザーが他のSPにログインしている場合、各SPのログアウト状況を示す単一のログアウト画面が表示され、ログアウトできないSPにはフラグが付けられます（一部のSPはSLOをサポートしていないか、現在ダウンしている可能性があります）。ログアウトする他のサービスプロバイダがない場合、SAMLセッションは終了し、IDプロバイダはそのセッションを破棄します。

SPからのSLO応答

ユーザーが（開始SP以外にも）追加のSPにログインしている場合、IdPはSAML LogoutRequest をそれぞれのSPに送信します。 Liferay が IdP の場合、 LogoutResponse は HTTP-Post、HTTP-Redirect、または SOAP バインディングを使用して送信されます。

各 SP は、 LogoutResponse を IdP に送信します。 Liferay が SP の場合、 LogoutResponse は HTTP-Post、HTTP-Redirect、または SOAP リクエストへの直接応答のいずれかを使用して送信されます。

すべての追加 SP が LogoutResponseを IdP に送信した後、IdP は SSO セッションを破棄します。 Liferay が IdP の場合、最後の SP が LogoutResponse を送信するか、タイムアウトすると、IdP は Liferay セッションを破棄し、ユーザーをログアウトします。

最後に、IdP は SLO を開始した SP に LogoutResponse を送信します。開始側のSPはSAMLセッションを終了し、ユーザーをログアウトします。

Liferay DXPでは、SAMLの設定はインスタンスレベルで定義されます。インスタンス内のすべてのサイトは同じ構成を共有します。

Liferayがサービスプロバイダー（SP）として構成されている場合、そのインスタンスは単一のSAMLエンティティを表します。カスタムドメインを持つサイトを含め、個々のサイトは個別のサービスプロバイダーを作成しません。

注

同一インスタンス内の個々のサイトに対して、個別のサービスプロバイダを定義することはできません。すべてのサイトが同じSAML設定を共有しています。