> ## Documentation Index
> Fetch the complete documentation index at: https://ai-kb.automationanywhere.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SSO メタデータ設定ガイド

> IdP を登録し、そのメタデータをアップロードすることで、オンプレミス EK インスタンスで SAML 2.0 SSO を有効にするためのステップバイステップの手順。

<Note>
  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.
</Note>

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

EK の SAML SSO が内部でどのように機能するかについて詳しく知らない方は、まず [SAML SSO 概要](/super-admin/sso/saml-sso-how-it-works) をお読みください。

## 前提条件

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

* **オンプレミス 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 は直接フェッチできます。

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

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

<AccordionGroup>
  <Accordion title="オプション 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 形式、署名証明書）を自動入力します。
  </Accordion>

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

    ```bash theme={null}
    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 の上書きの変更）にのみ、再エクスポートと再アップロードが必要になります。
  </Accordion>
</AccordionGroup>

### 手動構成（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 は署名されたアサーションを要求します。                                                                                    |

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

### 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 メタデータ タブを開く

<Steps>
  <Step title="EK にサインインする">
    スーパー管理者として EK にサインインします。
  </Step>

  <Step title="スーパー管理者ダッシュボードを開く">
    右上のアカウント メニューに移動し、**スーパー管理者ダッシュボード** をクリックします。
  </Step>

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

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

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

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

<Steps>
  <Step title="メタデータの追加ダイアログを開く">
    SSO メタデータ タブの右上の **メタデータの追加** をクリックします。まだドメインが構成されていない場合は、空の状態カードからもクリックできます。<br /><img src="https://mintcdn.com/automationanywhere/GwZtgh73O0-NsEVq/img/sa/sso/add-metadata-dialog.png?fit=max&auto=format&n=GwZtgh73O0-NsEVq&q=85&s=59176f248d196eb7d6ea959a50732843" alt="メタデータの追加ダイアログ" width="700" height="438" data-path="img/sa/sso/add-metadata-dialog.png" />
  </Step>

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

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

  <Step title="アップロード方法を選択し、XML を提供する">
    <Tabs>
      <Tab title="ファイルをアップロード">
        IdP 管理者が提供した `.xml` ファイルを選択します。`.xml` 拡張子を持つファイルのみが受け付けられます。
      </Tab>

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

  <Step title="送信する">
    **メタデータのアップロード** をクリックします。ダイアログが閉じ、トースト通知でアップロードが確認され、新しいドメインがテーブルに表示されます。
  </Step>
</Steps>

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

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

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

<Steps>
  <Step title="ドメインの行を見つける">
    SSO メタデータ テーブルでそのドメインを検索します。
  </Step>

  <Step title="更新をクリックする">
    その行のアクション列で **更新** をクリックします。
  </Step>

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

  <Step title="送信する">
    **メタデータの更新** をクリックします。置き換えは即座に有効になります。次回そのドメインの SSO サインイン時に新しいメタデータが使用されます。
  </Step>
</Steps>

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

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

次の用途に役立ちます:

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

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

<Steps>
  <Step title="削除をクリックする">
    その行のアクション列で **削除** をクリックします。
  </Step>

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

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

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

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

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

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

<Steps>
  <Step title="EK SP メタデータを IdP 管理者と共有する">
    フロントエンド ホストではなく、EK バックエンドからの SP メタデータを IdP 管理者に提供します。

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

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

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

      ```bash theme={null}
      curl -o ek_sp_metadata.xml https://<your-backend-host>/saml/well-known/sp-metadata
      ```
  </Step>

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

    * NameID がユーザーの電子メール アドレスに設定されていること。
    * アサーションが署名されていること。
    * Audience / Entity ID が EK の SP メタデータの値と一致すること。
  </Step>

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

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

  <Step title="サインインをテストする">
    実際の `@<domain>` ユーザーでテストします。ユーザーが正常に認証されたがアクセスを拒否された場合は、SAML アクセス制御の構成を確認してください。[**SAML アクセス制御**](/super-admin/sa-access-controls) ガイドを参照してください。
  </Step>

  <Step title="変更を文書化する">
    社内の変更管理システムに以下を記録します。ドメイン、IdP タイプ、アップロード日、およびアップロードを実行したスーパー管理者。
  </Step>

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

***

問題が発生しましたか？[SSO トラブルシューティングとリファレンス](/super-admin/sso/saml-sso-troubleshooting) ガイドを参照してください。