SSO メタデータ設定ガイド

注意

This guide is written for IT and identity administrators managing an on-premise EK instance. Any reference to "your IdP," "your IdP administrator," or "your email domain" refers to your organization's own infrastructure — not anything managed by Automation Anywhere.

このガイドでは、スーパー管理者が電子メール ドメインで SAML SSO を有効にする 2 つの部分のプロセスを説明します。まず、EK の SP メタデータを IdP と共有し、次に IdP のメタデータを EK にアップロードします。

EK の SAML SSO が内部でどのように機能するかについて詳しく知らない方は、まず SAML SSO 概要 をお読みください。

前提条件

始める前に、次のことを確認してください。

• オンプレミス EK デプロイメント は、ユーザーのブラウザからアクセス可能なバックエンド（<your-backend-host>）とフロントエンド（<your-frontend-host>）の両方で実行されています。IdP は、<your-backend-host>/user/generic/sso/saml/acs/admin で HTTP-POST SAML 応答を受信するだけで済みます。SP メタデータをダウンロード ファイルとして提供する場合、バックエンドへの直接アウトバウンド接続は必要ありません。
• スーパー管理者として EK にサインインしています。SSO メタデータ タブとその基盤となるすべてのエンドポイントは、スーパー管理者に制限されています。
• IdP は SAML 2.0 に準拠しており、SP メタデータ XML / URL を使用することも、SP エンティティ ID と ACS URL を使用して手動で構成することもできます。
• IdP は、urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress 形式を使用して、ユーザーの電子メール アドレスを SAML NameID として送信するように構成されています。EK は NameID を使用してユーザー アカウントを検索またはプロビジョニングします。
• SSO を有効にする 電子メール ドメイン がわかっていること（例: acme.com）。SSO はドメインによってキー設定されるため、そのドメインを共有するすべてのユーザー（alice@acme.com、bob@acme.com など）は同じ IdP にルーティングされます。
• デプロイメントが実行している フロントエンド SSO モード がわかっています。これは、フロントエンドの VITE_ALLOW_ONLY_SSO_LOGIN 環境変数によって制御されます。
  • true — シングルクリック SSO。ドメインは VITE_SSO_ENTERPRISE_ID によってハードコードされており、メタデータをアップロードするドメインと正確に一致する必要があります。
  • false (デフォルト) — 電子メールモーダル SSO。ドメインはサインイン時のユーザーの電子メールから導出されます。複数のドメインはそれぞれ独自のアップロードされたメタデータを持つことができます。

パート 1 — SP メタデータを IdP に提供する

IdP メタデータをアップロードする前に、IdP 管理者が EK を SAML アプリケーションとして IdP に登録する必要があります。EK は、パブリックでよく知られたエンドポイントを通じて SP メタデータを公開することで、これを簡単に実現します。手動でフィールドをコピーする必要はありません。

SP メタデータ エンドポイント

EK バックエンドは、SP メタデータを次の場所で公開します。

https://<your-backend-host>/saml/well-known/sp-metadata

応答は、インスタンスのエンティティ ID、ACS URL、必要な NameID 形式、および SP 署名証明書（構成時）を含む、標準に準拠した SAML 2.0 EntityDescriptor です。エンドポイントは設計上認証されていないため、IdP は直接フェッチできます。

ヒント

完全なリファレンス — エンドポイントの動作、サンプル XML、保証コンポーネントとオプション コンポーネント、およびオンプレミス オペレーターがデプロイ時に調整できるバックエンド環境変数（CUSTOM_ENTITY_ID_FOR_GENERIC_SSO、SAML_SP_CERT_FILE、SAML_SP_KEY_FILE）— については、SP メタデータ エンドポイント を参照してください。

SP メタデータを共有する方法

オプション A — URL を提供する

IdP が EK バックエンド ホストに到達できる場合は、IdP 管理者に既知の URL を直接送信します。

https://<your-backend-host>/saml/well-known/sp-metadata

多くの最新の IdP（Okta、Entra ID、Ping、OneLogin、Auth0 など）は URL から SP メタデータをインポートでき、SP 構成（エンティティ ID、ACS URL、NameID 形式、署名証明書）を自動入力します。

オプション B — ファイルをダウンロードして渡す

IdP がバックエンド ホストに直接アクセスできない場合（セグメント化されたネットワーク、エアギャップ環境、または IdP が企業境界外の SaaS である場合によく見られます）は、XML をダウンロードして帯域外で IdP 管理者に渡します。

curl -o ek_sp_metadata.xml https://<your-backend-host>/saml/well-known/sp-metadata

IdP 管理者は、IdP の SAML アプリケーション構成画面に ek_sp_metadata.xml をアップロードします。SP 構成が変更された場合（通常はバックエンドのホスト名の変更、SP 署名証明書のローテーション、またはエンティティ ID の上書きの変更）にのみ、再エクスポートと再アップロードが必要になります。

手動構成（IdP がメタデータを使用できない場合）

IdP でフィールドを手動で入力する必要がある場合は、SP メタデータ XML の値を使用します。最も一般的に必須のフィールドは次のとおりです。

フィールド	値
Entity ID / Audience	SP メタデータ応答の <md:EntityDescriptor> の entityID 属性。デフォルトでは ACS URL。デプロイ時に CUSTOM_ENTITY_ID_FOR_GENERIC_SSO で上書き可能。
ACS URL / Reply URL / Single Sign-On URL	https://<your-backend-host>/user/generic/sso/saml/acs/admin — 常にバックエンド ホストであり、フロントエンドではありません。
バインディング	HTTP-POST
NameID 形式	urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
AuthnRequests の署名	EK デプロイメントに SP 証明書が構成されている場合（メタデータで AuthnRequestsSigned としてアドバンス）は true。それ以外は false。
アサーションの署名要求	true — 常に。EK は署名されたアサーションを要求します。

警告

IdP はユーザーの電子メール アドレスを SAML NameID として送信する必要があります。IdP が不透明な内部 ID を代わりに送信した場合、サインインが失敗するか、キーが正しくないアカウントが作成されます。

IdP 管理者が返す必要があるもの

IdP で SAML アプリケーションが作成されたら、IdP 管理者に IdP SAML メタデータ XML を依頼してください。これはパート 2 でアップロードするファイルです。

ほぼすべての IdP がこのファイルを生成できます。IdP UI での一般的な名称:

IdP	見つけ方
Okta	アプリケーションの Sign On タブの 「Identity Provider metadata」 リンク
Entra ID / Azure AD	SSO ブレードの 「Federation Metadata XML」 ダウンロード
Ping / OneLogin / Auth0 / ADFS / Keycloak	一般的に 「Metadata」 または 「SAML Metadata」 と表記され、XML としてダウンロード可能

XML は、EK がアサーションを検証できるように、少なくとも IdP の entityID、SingleSignOnService の場所とバインディング、および IdP の署名証明書を含む IDPSSODescriptor を含む有効な SAML 2.0 EntityDescriptor である必要があります。

パート 2 — IdP メタデータのアップロード

IdP メタデータ XML を入手したら、それを EK インスタンスの電子メール ドメインに対して登録できるようになります。

SSO メタデータ タブを開く

1. EK にサインインする

   スーパー管理者として EK にサインインします。

2. スーパー管理者ダッシュボードを開く

   右上のアカウント メニューに移動し、スーパー管理者ダッシュボード をクリックします。

3. SSO メタデータ タブに移動する

   SSO メタデータ タブに切り替えます。既存のドメイン → メタデータのマッピングが3つの列で表示されるテーブルが見つかります。

   • SSO ドメイン — メタデータが登録されている電子メール ドメイン（例: acme.com）。
   • 更新日 — そのドメインのメタデータが最後にアップロードまたは置き換えられた日時。
   • アクション — その行の保存されたメタデータをダウンロード、更新、または削除するためのコントロール。

   右上の検索ボックスを使用して、ドメインでフィルタリングできます。テーブルは SSO ドメイン または 更新日 でソート可能です。

新しいドメインのメタデータを追加する

1. メタデータの追加ダイアログを開く

   SSO メタデータ タブの右上の メタデータの追加 をクリックします。まだドメインが構成されていない場合は、空の状態カードからもクリックできます。
   

2. 電子メール ドメインを入力する

   SSO チームの電子メール ドメイン フィールドに、SSO を適用するドメインを入力します（例: acme.com）。電子メール アドレスのドメイン部分のみを使用してください。@、パス、スキームは不要です。値は保存時に小文字に正規化されます。

   警告

   デプロイメントがシングルクリック SSO モード（VITE_ALLOW_ONLY_SSO_LOGIN=true）で実行されている場合、この値は VITE_SSO_ENTERPRISE_ID と正確に一致する必要があります。不一致の場合、SSO ボタンはアップロードされたメタデータがないドメインにユーザーをリダイレクトし、バックエンドで認証が失敗します。

3. アップロード方法を選択し、XML を提供する
   ファイルをアップロード

   IdP 管理者が提供した .xml ファイルを選択します。.xml 拡張子を持つファイルのみが受け付けられます。

   XML コンテンツを貼り付け

   IdP メタデータ XML をテキストエリアに直接貼り付けます。コンテンツは <?xml ...?> または <EntityDescriptor ...> で始まる必要があります。

4. 送信する

   メタデータのアップロード をクリックします。ダイアログが閉じ、トースト通知でアップロードが確認され、新しいドメインがテーブルに表示されます。

注意

各ドメインは同時にアクティブな IdP メタデータ ドキュメントを1つだけ持つことができます。同じドメインに対して再アップロードすると、既存のメタデータが置き換えられます。詳しくは、以下の 既存のドメインのメタデータを更新する を参照してください。

既存のドメインのメタデータを更新する

IdP は署名証明書をローテーションし、場合によってはエンドポイントを変更します。これが発生した場合は、IdP 管理者と調整して、IdP が新しいキーを使用してアサーションの署名を開始する 前 に、新しい XML が EK にアップロードされるようにしてください。

1. ドメインの行を見つける

   SSO メタデータ テーブルでそのドメインを検索します。

2. 更新をクリックする

   その行のアクション列で 更新 をクリックします。

3. 新しい XML を提供する

   SSO メタデータの更新 ダイアログが開き、ドメインが事前入力された状態でロックされています。更新時にドメインを変更することはできません。エントリを再利用する場合は、削除してから再追加してください。新しいドメインの場合と同じように、アップロード方法を選択して新しい XML を提供します。

4. 送信する

   メタデータの更新 をクリックします。置き換えは即座に有効になります。次回そのドメインの SSO サインイン時に新しいメタデータが使用されます。

現在保存されているメタデータをダウンロードする

行のアクション列にある ダウンロード アイコン をクリックします。ファイルは <domain>_saml_metadata.xml として保存されます。

次の用途に役立ちます:

• この EK インスタンスで現在どの IdP メタデータがアクティブであるかを確認する。
• 監査のためにセキュリティ チームまたはコンプライアンス チームにコピーを提供する。
• アップデートを実行する前にバックアップを取得する。

ドメインのメタデータを削除する

1. 削除をクリックする

   その行のアクション列で 削除 をクリックします。

2. 確認する

   確認ダイアログで警告を読み、確認チェックボックスにチェックを入れます — 「この操作により、このドメインのすべてのユーザーの SSO が無効になることを理解しています」 — そして 削除 をクリックします。

危険

削除は取り消せません。削除後:

• EK はそのドメインの IdP メタデータをファイルに持たなくなります。
• @<domain> ユーザーからの新しい SSO サインイン試行は失敗します。
• 既存のアカウント — 電子メール/パスワード、Google OAuth、または以前の SSO サインインでプロビジョニングされたアカウント — は 削除されません が、それらのユーザーは SSO 経由でサインインできなくなります。

ドメインの SSO を復元するには、IdP メタデータ XML を再度アップロードする必要があります。

エンドツーエンドのチェックリスト

オンプレミス EK インスタンスで新しい電子メール ドメインに対して SAML SSO を有効にする場合、これをランブックとして使用します。

1. EK SP メタデータを IdP 管理者と共有する

   フロントエンド ホストではなく、EK バックエンドからの SP メタデータを IdP 管理者に提供します。

   • IdP がバックエンドに直接到達できる場合は、次の URL を案内します。

     https://<your-backend-host>/saml/well-known/sp-metadata

   • それ以外の場合は、XML をダウンロードして帯域外に渡します。

     curl -o ek_sp_metadata.xml https://<your-backend-host>/saml/well-known/sp-metadata

2. IdP 管理者が SAML アプリケーションを作成する

   IdP 管理者が SP メタデータを入手したら、IdP で EK を SAML アプリケーションとして登録します。以下を確認してください。

   • NameID がユーザーの電子メール アドレスに設定されていること。
   • アサーションが署名されていること。
   • Audience / Entity ID が EK の SP メタデータの値と一致すること。
3. IdP メタデータ XML を受け取る

   アプリケーションが作成されたら、IdP 管理者に IdP メタデータ XML を依頼します。これは次のステップでアップロードするファイルです。

4. IdP メタデータを EK にアップロードする

   スーパー管理者として EK にサインインし、スーパー管理者ダッシュボード → SSO メタデータ を開き、メタデータの追加 をクリックします。電子メール ドメインを入力し、XML をアップロードします。

5. サインインをテストする

   実際の @<domain> ユーザーでテストします。ユーザーが正常に認証されたがアクセスを拒否された場合は、SAML アクセス制御の構成を確認してください。SAML アクセス制御 ガイドを参照してください。

6. 変更を文書化する

   社内の変更管理システムに以下を記録します。ドメイン、IdP タイプ、アップロード日、およびアップロードを実行したスーパー管理者。

7. メタデータの更新スケジュールを立てる

   IdP の署名証明書がローテーション予定の日付を記録し、その日付前に更新されたメタデータをアップロードするリマインダーを設定します。新しいメタデータが利用可能になったら、SSO メタデータ タブの 更新 アクションを使用してください。

---

問題が発生しましたか？SSO トラブルシューティングとリファレンス ガイドを参照してください。