SAML管理
SAML管理パネルは、SAMLインスタンスを構成するのに最適な場所です。 インスタンス設定の代わりにこれを使用すると、SAML管理を効率化できます。
Liferay 7.4 以降では、SAML がすぐに使用できます。 SAML コネクタ 2.0 をインストールする必要はありません。
SAML Admin を使用して、アイデンティティ プロバイダー (IdP)、サービス プロバイダー (SP)、およびそれぞれへの接続を構成できます。 アクセスするには、 グローバル メニュー (
) → コントロール パネル → SAML 管理を開きます。
3つのタブがあります。
全般: SAML SP または IdP を有効または無効にし、必要なキーストアを管理します。
サービス/アイデンティティプロバイダー: 選択した SAML ロールに基づいて、SP または IdP の基本構成と詳細構成を管理します。
アイデンティティ/サービス プロバイダー接続: SP (SAML ロールがアイデンティティ プロバイダーの場合) または IdP (SAML ロールがサービス プロバイダーの場合) への接続を管理します。 SP/IdP 接続は複数存在できます。
一般タブ
[一般]タブには、ロールに関係なくSAMLに適用されるオプションが表示されます。
有効: すべての設定が完了した後にこのボックスをオンにして、SAML認証を有効にします。
SAMLロール:SAMLロール(アイデンティティプロバイダーまたはサービス・プロバイダーのいずれか)を選択します。
Liferay DXP 2025.Q4 以降では、アイデンティティブローカーのロールも利用できます。 詳細については、 アイデンティティブローカー を参照してください。
エンティティ ID: このSAMLエンティティの一意の識別情報(IdPもしくはSP)。 最大1024文字まで使用可能です。
最初の保存後に証明書と秘密キーのセクションが表示され、 システム設定でキーストアを設定したときに生成されたキーが表示されます。 ここでは、新しい証明書を生成するか、別の場所で作成した証明書をインポートすることで証明書を置き換えることができ、また、証明書をダウンロードして別の場所にインポートすることもできます。
自動生成された証明書を置き換える必要がある場合は、次の操作を実行できます。
-
証明書の置き換えをクリックします。
-
[証明書を作成]タブは、デフォルトで有効になっています。 鍵の必要事項を入力してください。
-
完了したら、 「保存」をクリックします。
新しいキーの詳細が表示されました。
すでにキーを生成している場合は、そのキーを PKCS #12 アーカイブに保存して、Liferay DXP にインポートする必要があります。
-
証明書の置き換えをクリックします。
-
証明書のインポート タブをクリックします。
-
キーストアのパスワードを入力し、PKCS #12キーファイルをアップロードエリアにドロップするか、ファイルセレクタを使用して選択します。
これで鍵のインポートは完了です。
ID ブローカー
現在、この機能はベータ機能フラグ (SAML のアイデンティティ ブローカー サポート - LPD-29737) でサポートされています。 詳細については、 ベータ機能フラグ をお読みください。
-
SAML ロール フィールドから アイデンティティ ブローカー ロールを選択します。 このモードでは、Liferay は外部 ID プロバイダーと環境に設定されたサービス プロバイダー間のブリッジとして機能します。
-
アイデンティティ ブローカーを 2 つの部分で構成します。
-
各外部アイデンティティプロバイダーに対する サービスプロバイダー として Liferay を設定します。
-
Liferay を各ダウンストリーム サービス プロバイダーの アイデンティティ プロバイダー として設定します。
-
両側が設定されると、Liferay は各認証リクエストを正しい外部 IdP にルーティングし、返されたアサーションを検証して、ダウンストリーム SP に新しいアサーションを発行します。 これにより、Liferay がブローカーとして配置され、接続されているすべての IdP と SP にわたって継続的な認証フローが確立されます。
サービス・プロバイダー
-
SAMLロールフィールドから サービス・プロバイダー ロールを選択します。
-
証明書と秘密鍵セクションは、SAML用のキーストアを作成するためのものです。 [証明書を作成] をクリックし、以下の情報を入力します。
- 共通名(姓と名)
- 組織の名称
- 組織単位の名称
- 市町村名または地域名
- 州または地方の名称
- 国名
- キーストアの有効期間(期限が切れるまでの日数)
- 鍵のアルゴリズム(デフォルトはRSA)
- 鍵の長さ(ビット数)(デフォルトは2048)
- キーのパスワード
キーストアは、ファイルシステムストレージ(デフォルト)とドキュメントとメディアストレージの2つのストレージオプションがあることを覚えておいてください。 デフォルトでは、証明書は暗号化に
SHA256アルゴリズムを使用し、MD5とSHA256によって指紋認証と自己署名されます 。 必要な情報を入力したら、 [保存]をクリックします。 -
[保存]をクリックした後、証明書に関する情報の表示や証明書のダウンロードができることを確認します。 確認できれば、キーストアの作成に成功したことになります。
-
また、暗号化証明書を生成することも可能です。 これは、アサーションを暗号化するための別のキーです。 アサーションを暗号化したい場合は、そのためのキーを生成する必要があります。 手順は、上記手順2の証明書作成と全く同じです。
-
次に、アイデンティティ・プロバイダー接続を設定する必要があります。 [アイデンティティ プロバイダー接続] タブをクリックし、 [アイデンティティ プロバイダーの追加]をクリックします。
-
アイデンティティ・プロバイダーの名前、エンティティID、メタデータURLを入力します。 すでに別の Liferay DXP インストールをアイデンティティプロバイダーとして設定している場合は、次の情報を入力します。
- 名前: Liferay IdP
- エンティティ ID:[ID of IdP]
- 許容時刻誤差(クロックスキュー):SPとIdPの間の許容誤差をミリ秒単位で設定します。
- 強制認証: コンテキストに関係なく、IdP が再認証を強制するかどうか。
- メタデータURL:
http://localhost:8080/c/portal/saml/metadata(最初にこのURLをテストしてください) - 名前識別子の形式: 設定を参照してください。
- 属性マッピング: 設定を参照してください。
- キープアライブURL: 設定を参照してください。
重要Liferay Connector to SAML 2.0 アプリは、 SAML IdP メタデータファイルへの URL または 実際の(アップロードされた)SAML メタデータ XML ファイルの使用をサポートしています。 メタデータ URL フィールドに入力された値は、メタデータ URL があり、指定されたメタデータ XML ファイルがない場合にのみデータベースに保存されます。 そうでない場合、Liferay DXPはオリジナルのメタデータURL をデータベースに保持します。 この動作により、一度メタデータURLを指定すれば、常にデータベースにメタデータURLが保存されます。 これにより、以前に入力したメタデータURLやそのフォーマットを忘れてしまった場合でも、表示されているメタデータURLを見て、表示されているメタデータURLを修正するか、メタデータXMLファイルを指定して以前に保存したメタデータURLを上書きするかを選択できます。
-
最後に、証明書と秘密鍵の情報を保存し、アイデンティティ・プロバイダー接続を設定したら、[一般]タブの上部にある [Enabled]にチェックを入れ、 [保存]をクリックします。 LiferayがSAMLサービス・プロバイダーになりました。
SAMLサービス・プロバイダーのセッションは、アプリケーションサーバー上の通常のセッションに関連付けられていることに注意してください。 アプリケーションサーバーのセッション切れにより、サービス・プロバイダーのセッションは終了しますが、シングルログアウトは開始されません。
サービス・プロバイダーの設定
アサーション署名を必須にする: SAMLメッセージ全体に加えて、SAMLアサーションにIdPによる個別の署名を要求する場合は、このボックスをオンにします。
クロックスキュー: 設定を参照してください。
LDAPインポートを有効にする:このボックスをオンにすると、このSPのインスタンス設定で宣言されたLDAPサーバーからユーザー属性をインポートします。
Authnリクエストに署名しますか?: SP として設定されている場合、Authn リクエストに電子署名をします。
メタデータに署名しますか?: ピア SAML エンティティに送信されるメタデータに署名します。
SSLを必須にする: このボックスをオンにすると、すべてのSAMLメッセージの転送にSSLが必要になります。 ピアに送信されるメタデータ内のすべてのURLは、 https プロトコルがプレフィックスとして付くようになります。
ログインポートレットの表示を許可する: ログインリクエストにSAML IdPがマッチしない場合に、ログインポートレットの表示を許可します。 このシナリオのユーザーは、Liferay DXPにローカルでログインします。
SAML応答自体が署名されている限り、個々のアサーションに署名する必要はありません。 SP と IdP は、トランスポート レベルで暗号化を行うために、常に https 経由で通信する必要があります。
Liferay DXP は署名された SAML 応答を必要とします。 中間者攻撃が可能であり、アサーション内の情報が機密であると考えられる場合、署名と暗号化の両方を行うことができます。
複数のIdP接続を追加できます。 別のアイデンティティ・プロバイダーを追加するには、 [アイデンティティ・プロバイダーを追加] を再度クリックして、他のプロバイダーの詳細を入力します。 ユーザーがログインする際に、アイデンティティ・プロバイダーを選択するよう求められるので、ユーザーが認識できるようにプロバイダー名を記載しておいてください。
アイデンティティ・プロバイダー
-
SAML ロール フィールドから アイデンティティ プロバイダー ロールを選択します。
-
証明書と秘密鍵セクションは、SAML用のキーストアを作成するためのものです。 [証明書を作成] をクリックし、以下の情報を入力します。
- 共通名(姓と名)
- 組織の名称
- 組織単位の名称
- 市町村名または地域名
- 州または地方の名称
- 国名
- キーストアの有効期間(期限が切れるまでの日数)
- 鍵のアルゴリズム(デフォルトはRSA)
- 鍵の長さ(ビット数)(デフォルトは2048)
- キーのパスワード
キーストアは、ファイルシステムストレージ(デフォルト)とドキュメントとメディアストレージの2つのストレージオプションがあることを覚えておいてください。 デフォルトでは、証明書は暗号化に
SHA256アルゴリズムを使用し、MD5とSHA256によって指紋認証と自己署名されます 。 必要な情報を入力したら、 [保存]をクリックします。 -
[保存]をクリックした後、証明書に関する情報の表示や証明書のダウンロードができることを確認します。 確認できれば、キーストアの作成に成功したことになります。
-
また、暗号化証明書を生成することも可能です。 これは、アサーションを暗号化するための別のキーです。 アサーションを暗号化したい場合は、そのためのキーを生成する必要があります。 手順は、上記手順2の証明書作成と全く同じです。
-
次に、サービス プロバイダーの接続を構成する必要があります。 サービス プロバイダー接続 タブに移動し、 サービス プロバイダーの追加をクリックします。
-
サービス プロバイダーの名前を入力し、そのエンティティ ID とメタデータ URL を入力します。 サービスプロバイダーとして別の Liferay DXP インストールをすでに構成している場合は、次の情報を入力します。
-
最後に、証明書と秘密キーの情報を保存し、サービス プロバイダーの接続を構成した後、[全般] タブの上部にある 有効 ボックスをオンにして、 保存をクリックします。 Liferay は SAML アイデンティティプロバイダーになりました。
アイデンティティプロバイダの設定
メタデータに署名しますか?: ピア SAML エンティティに送信されるメタデータに署名します。
SSLを必須にする: このボックスをオンにすると、すべてのSAMLメッセージの転送にSSLが必要になります。 ピアに送信されるメタデータ内のすべてのURLは、 https プロトコルがプレフィックスとして付くようになります。
Authnリクエスト署名を要求する: このボックスをオンにすると、各Authnリクエストに送信元のサービス・プロバイダーによる署名が必要となります。 ほとんどの場合、これは有効になっているはずです。
セッション有効期間: IdPが管理するSSOセッションが継続する時間(秒)です。
セッション・アイドル・タイムアウト: アイドルセッションが期限切れとなるまでの時間(秒)。
SAML設定
多くの同じフィールドが、サービス・プロバイダーとアイデンティティ・プロバイダーの両方の設定に表示されます。 以下は参考です。
名前: SP または IdP に名前を付けます。 これは説明的な名前であり、構成では使用されません。
エンティティ ID: この SP または IdP の正式名。 接続を設定する場合は、この名前と一致させる必要があります。
有効: この SAML プロバイダーを有効にするには、このボックスをオンにします。
許容時刻誤差(クロックスキュー): SPとIdPの時差の許容誤差をミリ秒単位で設定します。
強制暗号化: SPがアサーションを暗号化するための公開鍵を提供しない場合、シングルサインオンを中止します。
Authnを強制する: このボックスをオンにすると、サービス・プロバイダーがユーザーを確認する前に、アイデンティティ・プロバイダーにユーザーの再認証を要求します。 複数の IdP が設定されている場合は、ユーザーが使用する IdP を選択できるようにこれを無効にします。 選択した IdP に対してすでに認証されている場合、ユーザーは再認証する必要はありません。
不明なユーザーは見知らぬ人です: 見知らぬ人の動作は、コントロール パネル → インスタンス設定 → プラットフォーム → ユーザー認証 → 全般で定義されます。
メタデータ: サービス・プロバイダーのメタデータXMLファイルのURLを指定するか、サービス・プロバイダーのメタデータXMLファイルを手動でアップロードしてください。 URLを指定すると、XMLファイルを取得し、定期的に更新のためのポーリングを行います。 更新間隔は、システム設定のランタイム メタデータ更新間隔プロパティ (秒数を指定) を使用して構成できます。 URLによるメタデータXMLファイルの取得に失敗した場合、サービス・プロバイダー接続を有効にすることはできません。 アイデンティティ・プロバイダーサーバーがURL経由でメタデータにアクセスできない場合、XMLファイルを手動でアッ プロードできます。 この場合、メタデータXMLファイルの自動更新は行われません。
名前識別子: SAML 仕様のセクション 8.3 で利用可能なオプションから名前識別子の形式を選択します。 サービス・プロバイダーが受信することを想定する内容に従って設定します。 Liferayサービス・プロバイダーの場合、メールアドレス以外の選択は、名前識別子がスクリーン名を指していることを示します。 これらのフォーマットは、Liferayアイデンティティ・プロバイダーにとって特別な意味を持ちません。 NameID の値は、名前識別子属性で定義されます。
ユーザーの解決: マッチなし、名前 ID の形式に応じて動的に選択されるユーザーフィールドにマッチする、または特殊な SAML 属性マッピングを使用してマッチする、から選択します。 このアルゴリズムは、ユーザーの検索方法またはプロビジョニング方法を決定します。 たとえば、名前 ID 形式に基づいて選択し、名前 ID 形式が電子メール アドレスである場合、アルゴリズムは電子メール アドレスによって一致します。
属性マッピング: LiferayからSAML属性とマッチするフィールドを選択します。 Liferayのユーザーオブジェクトからいくつかのフィールドを選択するか、ユーザーオブジェクトに作成したカスタムフィールドを選択することができます。 これらの属性は、ユーザーがシステムにログインしたときに、SAMLアサーションから更新されます。 デフォルトでは、 NameIDとサービス・プロバイダーは、 emailAddress が少なくとも1度マッチした後にユーザーにバインドされるようになっています。 バインディングは、ユーザーマッチングを行う前に優先的に確認されるため、メールアドレスが変更されたユーザーがログインできなくなることはなく、メールアドレスはSAML属性マッピングで修正することが可能です。 マッピングに使用できる Liferay 属性は、 emailAddress、 screenName、 firstName、 lastName、 modifiedDate、および uuidです。
キープアライブ: ユーザーが Liferay IdP 経由で複数の Liferay SP インスタンスにログインしている場合、そのうちの 1 つに対してブラウザ ウィンドウを開いたままにしておくと、セッションを維持できます。 SPがLiferay DXPの場合のみ設定します。 URLは https://[SPホスト名]/c/portal/saml/keep*aliveです。
クラスター環境で、Liferay DXPをSAMLサービス・プロバイダーとしてセットアップする
Liferay Connector to SAML 2.0 アプリをクラスター環境の SSO ソリューションとして使用できます。 複数ノードのクラスターがロードバランサーの背後にある場合、すべてのノードをSPとして有効にし、同じキーストアマネージャーを共有する必要があります。
ファイルシステム・キーストアマネージャーを使用する場合(デフォルト)、以下を行います。
-
上記のように、 Liferay クラスタ の各ノードを SAML サービス プロバイダーとして設定します。
-
キーストアファイル(
[Liferay Home]/data/keystore.jks、デフォルト)を、最初のノードから残りのノードにコピーします。 このファイルは、SAMLプロバイダーアプリで作成されるJavaキーストアです。 キーストアには、SAMLコネクターアプリが管理する有効な証明書または自己署名証明書が含まれます。 -
サービス・プロバイダーのメタデータが、URLまたはXMLファイルとして使用できるように生成されていることを確認します。 データベースバックエンドが同じであるため、メタデータはすべてのノードで同じです。 IdPのリクエストはロードバランサーを経由します。
-
この時点で、すべてのノードは同じ SAML SP 構成を持ち、各ノードは Web 要求に応答して SAML プロトコルを処理できます。 SSOソリューションをテストするには、ロードバランサー経由でLiferayにサインインし、いくつかの異なるサイトのいくつかのページに移動し、ログアウトしてください。
ドキュメントライブラリ・キーストアマネージャーを使用する場合、キーストアファイルは全ノードで共有されるデータベースに保存されるため、手順2をスキップします。
これで、Liferay DXP を SAML サービス プロバイダーとして設定する方法がわかりました。 また、クラスター環境でSAMLを構成する方法もわかりました。
Liferay 7.4 以降では、SAML がすぐに使用できます。 SAML コネクタ 2.0 をインストールする必要はありません。
OSGi構成プロパティ
OSGi 構成ファイル を介して UI 外部で SAML を構成したり、メタデータ XML をアップロードして接続のネゴシエート方法を構成したりすることができます。
前述したように、SP接続の設定に関することは、SAML管理UIで行う必要があり、そこで設定はLiferayのデータベースに保存されます。
SAML プロバイダー (IdP または SP) を構成するために、OSGi .config ファイルまたは Liferay DXP のシステム設定コントロールパネルアプリケーションを使用しないでください。 システム設定UIは自動生成されるもので、上級管理者向けです。 SAML管理UI が行うフィールドの強化された入力値の検証は行われないため、管理者は無効な設定を作成することができます。
これは、OSGi設定管理で管理できるポータルインスタンスに対応した設定です。 影響を受けるプロパティは、 SAMLProviderConfiguration メタタイプに含まれるものです。
keyStoreCredentialPassword()keyStoreEncryptionCredentialPassword()assertionSignatureRequired()authnRequestSignatureRequired()clockSkew()defaultAssertionLifetime()entityId()enabled()ldapImportEnabledrole()sessionMaximumAgesessionTimeout()signAuthnRequest()signMetadata()sslRequired()allowShowingTheLoginPortlet()
SAML管理UIは、ポータルインスタンススコープの構成インスタンスを作成する場所として残されています。
SamlConfigurationメタタイプで表される、システム全体の設定もあることに注意してください。
Liferay 6.2 を使用していた場合、次のシステム全体のプロパティが削除されていることに注意してください。
saml.metadata.paths(SP接続のデフォルトを削除した後は何の意味もありません。)saml.runtime.metadata.max.refresh.delaysaml.runtime.metadata.min.refresh.delay
後者の2つのプロパティは、単一のプロパティに置き換えられました。com.liferay.saml.runtime.configuration.SamlConfiguration.getMetadataRefreshInterval()
また、 コントロール パネル → システム設定 → セキュリティ → SSO における SAML KeyStoreManager 実装構成 の導入にも注意してください。 この構成のオプションについては、上記の システム レベルでの SAML の構成で説明されています。
最近のバージョンでは、 SHA256 が設定および鍵の生成に使用されるデフォルトの暗号化アルゴリズムです。 デフォルト設定は、SHA256、次に SHA384、そして SHA512 を経て SHA1にフォールバックしようとします。 SHA1 は潜在的に脆弱であるため、このプロパティを使用してブラックリスト化することが可能です。
blacklisted.algorithms=["blacklisted*algorithm*url", "another*blacklisted*algorithm*url"]
SHA1をブラックリスト化するには、以下のような設定になります。
blacklisted.algorithms=["http://www.w3.org/2000/09/xmldsig#sha1"]
これらをこの名前の設定ファイルに配置します。
com.liferay.saml.opensaml.integration.internal.bootstrap.SecurityConfigurationBootstrap.config
メタデータXMLを設定すれば、接続のネゴシエーションの方法をもっと細かく設定できます。
metadata.xmlによるネゴシエーションの設定
デフォルトのネゴシエーション設定がうまくいかない場合は、独自の設定を作成し、アップロードできます。 この作業を行う前に、ホストのメタデータURLにアクセスし、後で必要になる場合に備えて設定のコピーを保存しておいてください。
http://[hostname]/c/portal/saml/metadata
例えば、 SHA1しかサポートしていないレガシーIdPへの接続に行き詰まった場合、他のアルゴリズムを無効化する設定をアップロードできます。
<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="samlidp">
<md:IDPSSODescriptor WantAuthnRequestsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:Extensions>
<alg:SigningMethod xmlns:alg="urn:oasis:names:tc:SAML:metadata:algsupport" Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
</md:Extensions>
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>... omitted ...</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://localhost:8080/c/portal/saml/slo"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://localhost:8080/c/portal/saml/slo"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://localhost:8080/c/portal/saml/sso"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://localhost:8080/c/portal/saml/sso"/>
</md:IDPSSODescriptor>
</md:EntityDescriptor>
上記の構成では、 <md:Extensions> ブロックには署名アルゴリズムが 1 つだけあることに注意してください: SHA1。
デフォルト構成は SHA1にフォールバックするため、レガシーシステムがフォールバック メカニズムを介してネゴシエートできない場合を除き、これを行う必要はありません。 また、 SHA1をブラックリストに登録した場合、これは機能しないことに注意してください。 SHA1には の脆弱性があるため、可能であれば SHA1 の使用は避けるのが最善です。
メタデータ設定を変更した場合、変更前に保存していれば、デフォルトの設定に戻すことができます。 そうでない場合は、アップロードされたXMLファイルの代わりに、ピアのメタデータ設定の1つにURLを提供することができます。