4.7. SWG、RBI、WAIのためのSAMLサインオン¶
4.7.1. Shield 管理コンソールのSAML Sign-on¶
SAMLは、Adminコンソールにログインする管理者の識別と認証に使用することができます。
以下のステップに従います:
SAMLアプリケーションの作成¶
注意
ユーザー認証と同様、すべてのIdPに対応しています。 以下の例ではADFSを使用していますが、他のプロバイダーでも非常によく似ています。
アプリケーションを作成します。ユーザー認証と同じ手順で行います(選択したIdPに応じて、左のメニューの関連セクションを参照してください)。
- 表示名は、Shield アドミンに関連するものであることを示す必要があります。
- Shield adminを使用している場合、Service/Reply/Single Sign-on URL(名前はIdPによって異なります)には、この値を使用してください: https://admin.ericomcloud.net/api/auth/samlLoginRes_API
- Forcepointをご利用の場合は、URL: https://forcepoint.ericomcloud.net/api/auth/samlLoginRes_API をご利用ください。
- Netskopeをご利用の場合は、URL: https://netskope.ericomcloud.net/api/auth/samlLoginRes_API をご利用ください。
- ZT管理ポータルを使用している場合は、URL: https://ztadmin.ericomcloud.net/api/v1/saml/acs を使用します。
注意
Shield管理用の既存のSAMLアプリがあり、ZT管理ポータルを使用したい場合、既存のSAMLアプリに別のReply/ACS URLとしてztadmin URLを追加します。
Relying Party Trust Identifierには、このIdPごとにユニークな任意のテキストを使用します。このテキストは、後に Shield Tenant Admin で IdP Audience を構成するために使用されます。
処理を完了させます。
IdPからメタデータファイルをShieldにインポートします。
ADFSの例¶
名前IDの追加請求¶
注意
ADFSに必要なものです。
Relying Party Trustを右クリックし、Edit Claim Issuance Policyを選択します。
ルールの追加|クレームルールのテンプレート=LDAP属性をクレームとして送信します。「次へ」をクリックします。
以下のリストから選択し、手続きを行ってください。
Shieldの設定¶
Admin Console|Authentication|SAML Authentication(Admin Console)」に移動します。
メタデータXMLをインポートするか、以下のフィールドを入力します(その他のフィールドはオプションです):
- IdPログインURL
- IdP Signing Certificate
- IdP Audience
これらのフィールドは、特定の IdP ごとに、SAML 認証(エンド・ユーザー)設定と同じ方法で入力する必要があります。必ず「保存」をクリックしてください。
管理者ユーザーに対するSAML認証の有効化¶
これらのフィールドを設定した後、Ericomサポートに連絡して、テナントのSAML認証を有効にする必要があります。
Ericomのサポート担当者がお客様のテナントに対してこの機能を有効にした場合、ページを更新して「有効|はい」を選択することができるはずです。
[保存]をクリックし、[Admin Console]から[Sign Out]をクリックします。
SAML認証情報を使用してログインする場合は、こちらの指示に従ってください。
4.7.2. SWG、RBI、WAIのためのSAMLサインオン¶
SWG、RBI、WAIのSAML統合の説明です。ZTEdge ClientおよびZTNAの使用には適用されません。
重要
ZTEdgeクライアント、ZTNA、またはEricom内蔵のIdentity Providerで使用するためにSAML認証を設定する場合は、IdPのドキュメントを参照してください。
このセクションのドキュメントは、以下に適用されます。
- Shieldプロキシモード(PACファイル含む)
- プロキシレス(リダイレクション)モード
- WAIポータル
- 管理者コンソール
SAMLによる認証時にユーザを特定し、SAMLプロバイダから渡された情報(グループ名など)を元にプロファイルを割り当てることができます。
注意
HTTP プロキシを使用する場合、お客様のドメイン (例: company.com) をテナントで設定する必要がある場合があります。この場合、Ericom社のテクニカルサポートにお問い合わせください。
SAML を介して Shield にログインする場合、エンドユーザは IDP(Identity Provider)にログインするよう促される。エンドユーザが IdP から適切な SAML アサーションを既に受け取っている場合は、再ログインする必要はありません。
重要
SAML ID プロバイダに Shield を追加する前に、ID プロバイダが完全に機能していることを確認してください。 Ericom テクニカルサポートでは、サードパーティーの ID プロバイダーの設定に関するサポートは行っていません。
SAML認証を使用するには、以下の基本的な手順に従います。
アイデンティティ・プロバイダー(IdP)
- SAMLアプリケーションの作成(Shield用)
- アプリケーションをユーザーに割り当てる
- アトリビュート値の設定(例:Audience)
- Ericom Shield ACS: https://shield.ericomcloud.net/saml/assert OR Ericom WAI ACS: https://<WAI-PORTAL-NAME>.ericomcloud.net/saml/assert を入力してください。
お知らせ
ShieldとWAIの両方でSAML認証を使用したい場合は、IDプロバイダ(サポートされている場合)に両方のACS URLを入力します。
Ericom Shield Admin ポータルで - IdP 設定をインポートまたは定義します。
- ログインURL
- 署名証明書
- 復号化キー
- オーディエンス
注意
サードパーティのプロキシを使用して Shield にトラフィックを転送している場合は、転送ポリシーで shield.ericomcloud.net が Shield に送信されることを確認してください。このドメインが転送ポリシーになく、インターネットに直接送信された場合、SAMLログインは失敗します。
SAML インポート IDP メタデータ¶
多くの場合、「IDPメタデータのインポート」ボタンを使って、IDプロバイダのメタデータをインポートします。
という選択肢もあります。
SAML メタデータ URL - メタデータ情報への URL を貼り付ける。
SAML Metadata XML File - メタデータ情報をファイルからアップロードする。
インポートが完了したら、インポートした設定がフィールドに入力されていることを確認し、「IDP Audience」がない場合は追加してください。IDP Audience はShieldとそれぞれのIDP設定の間で同じである必要があります。
SAMLプロバイダー別の詳しい説明は、左のメニューからご覧ください。
注意
SAMLは、管理者コンソールに接続する管理者ユーザーを認証するために使用することができます。
テナントログイン¶
注意
このセクションは、HTTPプロキシにのみ適用されます。
エンドユーザがEricomに初めて接続すると、テナントログインのプロンプトが表示されます。
ユーザーのメールアドレスを入力すると、設定されているテナントが選択されます。
注意
メールドメイン(例:contoso.com)がテナントに設定されている必要があります。設定されていない場合は、テクニカルサポートにお問い合わせください。
電子メール・アドレスを入力すると、SAML ID プロバイダのログイン画面が表示されます。
注意
クッキーがブラウザに保存されるので、次回以降のログイン時にテナントログイン画面に入る必要はありません(クッキーをクリアするまで)
ログイン時にエラーが発生した場合は、SAMLエラーコードの表を参照してトラブルシューティングを行ってください。
4.7.3. Microsoft Azure¶
Azureでアプリケーションを公開するには、Azureサブスクリプションのグローバル管理者権限が必要です。
グローバル管理者の資格情報を使用して、Azureポータルにログインします。
SAMLアプリケーションの作成¶
「Azure Active Directory」→「Enterprise applications」と進みます。
新規アプリケーションを選択します。
「Create your own application(独自のアプリケーションを作成する)」を選択します。
アプリケーションの名前を入力し、[作成]をクリックします。
アプリケーションが正常に作成されたら、シングルサインオンを選択します。
サインオン方法として、SAMLを選択します。
編集(ペンのアイコン)をクリックして、SAML基本構成を編集します。
以下の項目を入力してください。
- 識別子 : 任意の文字列(大文字・小文字を区別する)
- 返信用URL : 本来はhttps://shield.ericomcloud.net/saml/assert/
例)
[保存して閉じる]をクリックします。
Edit(ペンのアイコン)をクリックして、User Attributes & Claims を編集します。
[新しいグループ請求の追加]をクリックします。
Shield属性を追加します。(オプション)
例)
注意
Shieldプロファイルは、グループ名ではなく、グループ ID と関連付ける必要があります。AzureAD のグループ ID は、Azure AD の「グループ」画面で確認することができます。
[保存して閉じる]をクリックします。
Shieldの設定¶
Admin Console|Authentication|SAML Authentication に移動します。以下のフィールドに入力します(他のフィールドは任意です)。
IdPログインURL¶
このフィールドは、Azure のログイン URL です。[Azure Application | Single Sign-On]タブに移動し、Login URLの値をコピーして、Shieldのこのフィールドに貼り付けます。
IdP署名証明書¶
このフィールドは、Azure の証明書です。[Azure Application | Single Sign-On | SAML Signing Certificate] で証明書 (Base64) を探し、ダウンロードします。
このファイルを開き、base64エンコードされた文字列(BEGIN CERTIFICATEとEND CERTIFICATEの間にある)をコピーします。これをShieldのIdP Signing Certificateフィールドに貼り付けます。
設定結果例)
IdP Audience¶
Azure アプリケーションの Identifier (Entity ID) の文字列と同じものを使用します (大文字と小文字を区別します)。
Shield Proxy の設定と SAML サービス URL の除外¶
4.7.4. AD FS¶
AD FSをShield IdPとして使用するためには、以下の手順が必要です。
- ドメインコントローラーにADFS Relying Partyを設定する。
- ShieldがIdPとしてADFSを使用するように設定する。
- Shield Proxyを使用するようにブラウザを設定する。
ドメインコントローラーに ADFS Relying Party を設定する¶
Active Directory フェデレーションサービス(AD FS)のインストールをします。
ドメインコントローラーで、「管理」⇒「役割と機能の追加」⇒「次へ」を選択します。
Server Rolesを選択し、Active Directory Federation Servicesのチェックボックスを有効にします。
「次へ」をクリックします。
以下のようにサービスを設定します。
リライングパーティトラストの追加¶
AD FSは、Shieldを "Relying Party"(保護されたリソースへのアクセスを許可するサービスプロバイダ)として許可するように設定する必要があります。
ドメインコントローラーで、AD FS Managementを起動します。
左ペインで、Relying Party Trustを右クリックし、Add Relying Party Trust…を選択します。
Relying Party Trustを以下のように設定します。
暗号化証明書の設定は任意です。
サービスのURLを設定します - https://shield.ericomcloud.net/saml/assert/
Relying Party Trust IDを設定する。AD FS上で一意である任意の文字列を使用します。
重要
この値は、Admin | Authentication | SAML Authentication | Idp Audience で使用します。これらの値は一致する必要があります。
AD FSは、この文字列を使用して、どの依拠当事者を使用するかを特定します。
クレーム発行方針の編集¶
クレームは、ユーザーが認証されるとAD FSが依拠当事者に送信する属性となります。クレームにはLDAP属性とカスタム属性があります。
Relying Partyを右クリックし、Edit Claims Issuance Policy…を選択します。
「ルールの追加…」をクリックします。
LDAP Attributes as Claimsを選択します。
ユーザーLDAPグループ属性の追加¶
LDAPユーザーグループごとに異なるShieldプロファイルを設定するためには、Shieldにグループ情報を送信するためのクレームを作成する必要があります。
注意
Active DirectoryにShield専用のグループを作成することをお勧めします。これらのグループは、Shield_という構文を使用する必要があります(例:Shield_Marketing)。
カスタムルールの新規追加
ルールの名前を指定します : AdGroups(アドグループ)
カスタムルールとして以下のテキストを追加します。
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> add(store = "Active Directory", types = ("Shield-Groups"), query = ";tokenGroups;{0}", param = c.Value);
- 2つ目のCustom Ruleを追加します。
- ルールに名前をつけます : ShieldGroups(Shieldグループ)
- カスタムルールとして以下のテキストを追加します。
- SHIELDは他の正規表現に置き換えて、上で作成した適切なグループを見つけることができます。
c:[Type == "Shield-Groups", Value =~ "^(?i)SHIELD"]
=> issue(claim = c);
ADFSをIdPとして使用するためのShieldの設定¶
ADFSのメタデータを取得する¶
設定するデータを取得するために、AD FSのメタデータを取得します:ブラウザで、このURLにアクセスします。
https://<ADFSServiceURL>FederationMetadata/2007-06FederationMetadata.xml
FederationMetadata.xmlというファイルがダウンロードされます。このファイルを表示し、Tenant Admin UI のフィールドごとに以下のように値をコピーします。
テナント管理UI¶
[テナント管理]-[認証]-[SAML認証]を開き、以下の設定を行います。
有効 | 真 |
---|---|
IdPログインURL | この値はFederationMetadata.xmlに表示されます - "Location="を検索してください。例: https://<ADFSServiceURL>/adfs/ls |
IdP署名証明書 | FederationMetadata.xmlからX509Certificateをコピーします。use="signing"を検索し、証明書の内容をコピーして、このフィールドに貼り付けます。 |
IdP復号化キー | 以下の説明を参照してください。 |
IdP Audience | Relying Party Trust IDとして使用されたものと同じ文字列を使用する。 |
暗号化された SAML を構成する¶
注意
このステップはオプションです。AD FSとShieldを暗号化通信で設定する場合のみ必要です。
秘密鍵付き証明書の作成¶
以下のコマンドを使用します。
openssl req -nodes -sha256 -newkey rsa:2048 -keyout encr.key -out request.csr
openssl x509 -req -days 365 -sha256 -in request.csr -signkey encr.key -out encr.cer
AD FSを暗号化するための設定¶
AD FS管理で - Relying Party を右クリックし、Propertiesを選択します。
「暗号化」タブで、「参照」をクリックし、最近作成したencr.cerファイルをインポートします。
復号化のためのShieldの設定¶
テナント管理|認証|SAML に移動し、最近作成した encr.key の内容で IdP Decryption Key を設定します。
Shield Proxy の設定と SAML サービス URL の除外¶
4.7.5. Okta¶
SAMLアプリケーションの作成¶
Oktaのユーザーアカウントに接続するか、開発/プレビュー用アカウントを作成します。プレビュー用アカウントを新規に作成する場合は、こちらにアクセスし、指示された手順に従ってください。
セレクトパートナーインテグレーション&シングルサインオン
新しいアカウントを有効化します(電子メールで送信)。指定された認証情報を使用してログインします(仮パスワード付き)。ログイン後、最初のページで、クラシックUIに切り替えます。
Adminをクリックします。
アプリケーションをクリックします。
[アプリケーションの追加]、[新しいアプリの作成]の順にクリックします。
プラットフォームの種類として、Web を選択する。SAML 2.0サインオン方式を選択します。
「作成」をクリックし、次のフォームにアプリケーション名やロゴなどを記入します。
「次へ」をクリックします。
SAML設定(フィールド名と割り当てる値)を設定します。
シングルサインオンのURLを設定します - https://shield.ericomcloud.net/saml/assert/
シングルサインオンURL | https://shield.ericomcloud.net/saml/assert/ |
受信者URLと送信先URLに使用します。 | チェックボックスを有効にしたままにします。 |
オーディエンスURI | 任意の文字列(Admin|Authentication|SAML Authentication|Idp Audienceと一致する必要があります)。 |
デフォルトのリレー状態 | https://shield.ericomcloud.net/saml/assert/ |
グループ属性ステートメントを定義する方法は以下のとおりです。
アプリケーションのユーザーグループへの割り当て¶
グループの作成¶
[ディレクトリ]メニューから[グループ]をクリックします。
[グループの追加]をクリックし、グループ名を入力してから[グループの追加]ボタンをクリックします。
グループで、「人の管理」をクリックし、このグループのユーザーを追加します。
アプリケーションをこのグループに割り当てる¶
作成した SAML アプリケーションに戻ります。「Assignment」タブで「Assign」をクリックし、「Assign to Group」をクリックします。
割り当てるグループを選択し、[割り当てる]をクリックします。
グループ属性の設定¶
SAML 応答でグループ名を送信するようにアプリケーションを構成します。General タブで、SAML Settings の下の Edit をクリックします。次のページに移動します。「Group Attribute Statements」の下に、グループを追加します。
属性の名前を追加します。Shield-Groupsを追加します。
グループ名を追加するフィルタを定義します。
たとえば、ここでは、"Shield "という単語を含むグループ名を含めるように、アプリケーションに指示します。つまり、ユーザが "Shield" というグループのメンバである場合、このグループ名が SAML 応答に含まれることになります。
ユーザーのグループリストを取得するために、正規表現 .* にマッチします。
この場合、ShieldはSAMLレスポンスで読み込まれた最初のGroupと一致します。
「次へ」をクリックし、「完了」をクリックします。
Shieldの設定¶
「Admin Console|Authentication|SAML認証(エンドユーザー)」を開き、以下の項目を設定します。
IdPログインURL(必須)¶
OktaのSign Onタブで、リンクIdentity Provider metadataを見つける。XML文書が表示されます。
md:SingleSignOnServiceタグを探し、Location属性の値をコピーしてください。
Shield の IdP Login URL 欄に貼り付けます。
IdP Signing Certificate(必須)¶
同じXMLの中で、ds:X509Certificateというタグを見つけ、このタグの値(base64でエンコードされた文字列)をコピーしてください。
ShieldのIdP Signing Certificateの欄に貼り付けます。
IdP復号化キー(オプション)¶
Okta は、セキュリティ向上のため、暗号化された SAML 応答を送信するように構成することができます。そのためには、Oktaに証明書を設定し、その秘密鍵をShieldに提供して、SAML応答を復号化できるようにします。
証明書署名要求(CSR)の生成¶
コマンドシェルから、実行します。
openssl req -nodes -sha256 -newkey rsa:2048 -keyout PrivateKey.pem -out CertificateRequest.csr
証明書の属性に関する質問に答えます。すべてのデフォルト値を受け入れるには、Enter を入力します。
証明書の作成¶
作成したCSRを使い、秘密鍵で署名し、公開証明書を作成します。
openssl x509 -req -days 365 -sha256 -in CertificateRequest.csr -signkey PrivateKey.pem -out idp.crt
Oktaの設定¶
[SAML 設定] で [詳細設定の表示] をクリックします。
詳細設定で、アサーションを暗号化するように設定し、証明書(上の例ではidp.crt)をアップロードします。
PrivateKey.pemからbase64値をコピーします。
ShieldのIdP Decryption Keyフィールドに文字列を貼り付けます。
IdP Audience (必須)¶
OktaのAudience URIフィールドに入力された文字列と同じものを使用します。
Shield Proxy の設定と SAML サービス URL の除外¶
4.7.6. Ping Identity¶
PingでSAMLアプリケーションを作成する¶
Web App SAML アプリケーションを新規に作成します。
Provide App Metadata を Manually Enterに変更します。
ACSのURLは、https://shield.ericomcloud.net/saml/assert/ を入力します。
Entity IDまでスクロールし、Shieldを入力します。
バインディングがHTTP POSTを使用していることを確認します。
Attribute Mappingで、Name ID属性に有効なPING属性を渡します。
PING属性が空の場合、1009エラーが返されます。
設定を保存すると、アプリケーションが作成されます。
次に、「Configuration」から、Shieldの設定に必要なMETADATAファイルをダウンロードします。
Shieldの設定¶
管理者コンソールにログインし、「認証」→「SAML認証(エンドユーザー)」を選択します。
Ping METADATA ファイルを開きます。
X509Certificatesの内容をコピーします。
Shield IdP Signing Certificateに貼り付けます。
HTTP-POST SSO Location URLをコピーします。
Shield IdP Login URL に貼り付けます。
最後に、Idp Audienceに「Shield」を入力し、設定を保存してください。
今すぐShieldで接続テストすると、Pingのログイン画面が表示されます。
4.7.7. Google SAML¶
Shieldとの連携¶
以下の手順に従って、GoogleをSAML IDプロバイダとしてShieldに統合してください。
Googleの設定¶
Google 管理コンソールで、「Google Workspace|Webとモバイルアプリ」にアクセスします。
新しい SAML アプリケーションを追加します。
ACSのURLを入力: https://shield.ericomcloud.net/saml/assert
一致するエンティティID(例:Shield)を入力します。
Ericom SAMLアプリケーションに必要なユーザーを割り当て、アクセスを許可します。
設定終了後、Sheild管理コンソールにインポートするためのメタデータをダウンロードします。
Shieldコンフィグレーション(エンドユーザー)¶
Shieldの管理者コンソールにログインし、「認証|SAML認証(エンドユーザー)」に移動します。
SAML認証の有効化(エンドユーザー)¶
[IDPメタデータのインポート]をクリックします。
Googleで設定したEntity ID(例:shield)を入力します。
設定を保存します。
ユーザーにShieldを使用するように指示して、Googleログインをテストします。
お知らせ
SAML認証でShieldにアクセスする場合は、HTTPSプロキシを使用することをお勧めします(例: <TENANT-TD>.proxy.ericomcloud.net:3443)
パスグループ¶
Ericom ShieldにGoogleグループを渡して、特定のProfileを有効にします。 Google 'SAML attribute mapping'に、GoogleグループをShield-Groups属性にマップするMappingを追加する。
Shield-Groupsの値がテナント内の有効なプロファイルと一致しない場合、組み込みの「Default - All」ポリシーが使用されます。
注意
競合を避けるために、グループのリストではなく、1つの値を属性に渡します。
Shield Admin Portalの設定¶
この構成は、ACS の URL を除き、エンドユーザーの構成と同様です: https://admin.ericomcloud.net/api/auth/samlLoginRes_API
4.7.8. miniOrange Xecurify¶
SAMLアプリケーションの作成¶
新しい SAML アプリケーションを作成します。
カスタムアプリケーション名 Shield¶
SPエンティティID:shield(仮、アプリ作成後、後で置き換わる予定です)
ACS URL:https://shield.ericomcloud.net/saml/assert
[詳細設定]をクリックします。
Sign Response を有効にします。
[保存]をクリックして、設定を完了します。
アプリ作成後、Metadataファイルを開き、「IdP Entity ID or Issuer」文字列をコピーします。
アプリのプロパティを開き、SPエンティティIDをこの値に設定します(オーディエンスIDも自動入力されます)。
Shieldの設定¶
管理者コンソールにログインし、「認証」→「SAML認証(エンドユーザー)」を選択します。
Enabled を Yes に設定します。
IdPログインURL : XecurifyのメタデータファイルからURLを取得する
署名用証明書 : Xecurifyメタデータファイルから証明書文字列を取得する
IdP Audience : XecurifyからURLを取得する。
4.7.9. Cisco Duo Access Gateway¶
SAMLアプリケーションの作成¶
Duo Access Gateway にログインし、新しい SAML アプリケーションを追加します。
サービスプロバイダの項目で、入力します。
エンティティID : ericom
ACS URL : https://shield.ericomcloud.net/saml/assert
[保存]をクリックします。
Ericom Shieldの設定に使用するため、Metadata URLを開いてください。
Shieldの設定¶
Duo METADATAファイルを開き、内容を準備します。
管理者コンソールにログインし、「認証」→「SAML認証(エンドユーザー)」を選択します。
Enabled を Yes に設定します。
Shield IdPのログインURLです。<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location= (引用符なし)> の値をコピーして、以下のように記述します。
IdP Signing Certificateを使用します。X509Certificatesの内容をコピーします(<ds:X509Certificate>と</ds:X509Certificate>の間の文字列のみです)。
IdP Audience : Entity IDの値を入力します。
プロキシ例外リストの設定¶
各エンドユーザーシステムで、プロキシが設定されているプロキシ例外リストに*.duosecurity.comを追加します。
たとえば、プロキシがWindowsプロキシ設定で構成されている場合、ここに例外を追加します。
4.7.10. トラブルシューティング¶
401エラー¶
IDプロバイダーにログインした後、401エラーが返される。
考えられる解決策¶
- Shieldの管理コンソールで、証明書の文字列に含まれるスペースを削除します(これらは隠し文字です)。
- Shieldの管理コンソールで、IdPログインURLが正しいことを確認してください(httpsかhttpかなど)。
- Audience IDが双方とも正しいことを確認してください。
テナント認証が成功しない¶
テナントログインにメールアドレスを入力すると、リフレッシュされる。
プロキシ回避リストにIdPのドメインを追加します。 例えば、Windowsの場合、例外リストに*.duosecurity.comを追加します。
IdP認証は繰り返し行われる¶
ACSのURLが正しいか確認してください(例:https://shield.ericomcloud.net/saml/assert/)。
認証に失敗し、不正なSAML ACSが表示される¶
SAML ID プロバイダーへのログインは成功しましたが、Shield の起動に失敗し、エラーメッセージ(またはログエントリ)に不正な ACS が使用されていることが表示されます。
考えられる解決策サードパーティのプロキシを使用してShieldにトラフィックを転送している場合、転送ポリシーで shield.ericomcloud.net が Shield に送信されていることを確認します。このドメインが転送ポリシーになく、インターネットに直接送信された場合、SAMLログインは失敗します。