> ## 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.

# EK の SAML SSO — 仕組み

> 構成を開始する前に、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>

EK はオンプレミス展開で **SAML 2.0 SSO** をサポートしており、ユーザーが組織の既存の **アイデンティティ プロバイダー (IdP)** を通じてサインインできるようになります。セットアップはすべて **スーパー管理者ダッシュボード → SSO メタデータ** タブを通じて行われ、コードを変更する必要はありません。

EK は、**標準に準拠した SAML 2.0 IdP**（Okta、Azure AD / Entra ID、Ping、ADFS、OneLogin、Auth0、Keycloak、Google Workspace など）で動作します。電子メール ドメインの IdP メタデータをアップロードすると、EK はそのドメインに属するユーザーに対して SSO を自動的にルーティングします。

## 2 つの EK ホスト名を理解する

オンプレミス EK デプロイメントには、異なる役割を持つ 2 つのホスト名があります。

* `<your-backend-host>` — すべての SAML トラフィック（SP メタデータ、SSO 開始、ACS エンドポイント）を処理します。**これは IdP が把握する必要がある唯一のホストです。**（例: `ek-api.corp.acme.com`）
* `<your-frontend-host>` — ユーザーがブラウザで開く Web UI です。EK は、`FRONTEND_ROOT_URL` 環境変数で構成されたサインインに成功した後、ユーザーをここにリダイレクトします。**このホストは IdP 構成には表示されません。**（例: `ek.corp.acme.com`）

## EK での SAML SSO の仕組み

SAML SSO を設定するには、2 つのシステム間で相互の信頼を交換する必要があります。認証が行われる前に、双方が相手が誰であるかを知る必要があります。

<CardGroup cols={2}>
  <Card title="Service Provider (SP) — EK" icon="server">
    お客様のオンプレミス EK インスタンスです。EK は SP メタデータを公開し、IdP が SAML 応答を送信すべき場所、使用する NameID 形式、および AuthnRequests で信頼すべき署名証明書を確認できるようにします。
  </Card>

  <Card title="Identity Provider (IdP) — お客様の組織" icon="shield-halved">
    組織の Okta、Entra ID、Ping、ADFS などです。IdP は、発行者、SSO エンドポイント、署名証明書を記述するメタデータ XML を公開します。EK は IdP が返すアサーションを検証するためにこれを必要とします。
  </Card>
</CardGroup>

電子メール ドメイン（例: `acme.com`）の SSO を有効にするには、スーパー管理者はこの交換の両側を完了する必要があります。

<Steps>
  <Step title="IdP と SP メタデータを共有する">
    IdP 管理者に、EK インスタンスが公開する SP メタデータを提供し、IdP で EK を SAML アプリケーションとして登録できるようにします。
  </Step>

  <Step title="IdP メタデータを EK にアップロードする">
    IdP アプリケーションが作成されたら、その IdP メタデータ XML を **スーパー管理者 → SSO メタデータ** を通じて EK にアップロードし、ユーザーがサインインする電子メール ドメインに関連付けます。
  </Step>
</Steps>

両方の設定が完了すると、`@<domain>` で終わる電子メールを持つユーザーは、企業 IdP を介して SAML SSO 経由で EK にサインインできます。

## ユーザーが SSO フローに到達する方法

EK サインイン画面には、常に「SSO でサインイン」オプションが表示されます。ユーザーがクリックしたときに何が起こるかは、EK Web UI ビルドに組み込まれた 2 つのフロントエンド環境変数によって異なります。

| 変数                          | 目的                                            |
| --------------------------- | --------------------------------------------- |
| `VITE_ALLOW_ONLY_SSO_LOGIN` | ログイン画面が使用する SSO モードを決定します。                    |
| `VITE_SSO_ENTERPRISE_ID`    | シングルクリックモードで、認証対象の電子メール ドメインを指定するためにのみ使用されます。 |

<AccordionGroup>
  <Accordion title="モード A — シングルクリック SSO（VITE_ALLOW_ONLY_SSO_LOGIN=true）">
    ログイン画面には SSO ボタンのみが表示され、電子メール アドレスやパスワードのフィールドは表示されません。これは、単一の電子メール ドメインにサービスを提供するオンプレミス展開の一般的なセットアップです。

    ユーザーがボタンをクリックすると、フロントエンドは `VITE_SSO_ENTERPRISE_ID` を読み取り、すぐに次の場所にリダイレクトします。

    ```
    https://<your-backend-host>/sso/login?enterprise_id=<VITE_SSO_ENTERPRISE_ID>&target_url=https://<your-frontend-host>/okta/authenticate
    ```

    これを機能させるには:

    * `VITE_SSO_ENTERPRISE_ID` はフロントエンドで設定されている必要があります。
    * その値は、**SSO メタデータ** タブに IdP メタデータがアップロードされたドメインと一致する必要があります。
    * メタデータをアップロードする場合、**SSO チームの電子メール ドメイン** は `VITE_SSO_ENTERPRISE_ID` と正確に一致する必要があります（大文字と小文字は区別されません。値は保存時に小文字に正規化されます）。

    `VITE_SSO_ENTERPRISE_ID` が設定されていない場合、ユーザーには *「SSO ログインのドメインを決定できませんでした」* が表示され、続行できません。設定されていてもそのドメインにメタデータが存在しない場合、リダイレクトは実行されますが、SSO はバックエンドで失敗します。
  </Accordion>

  <Accordion title="モード B — 電子メールモーダル SSO（VITE_ALLOW_ONLY_SSO_LOGIN=false、デフォルト）">
    ログイン画面には、電子メール/パスワードと SSO コントロールが一緒に表示されます。SSO ボタンをクリックすると、*「電子メールを入力してください」* モーダルが開きます。ユーザーが電子メールを送信した後、フロントエンドはドメインを抽出し、`POST https://<your-backend-host>/sso/verify_enterprise_id` 経由でバックエンドが SSO を構成しているかどうかを確認します。

    * **はい** の場合、フロントエンドは以下にリダイレクトします。

      ```
      https://<your-backend-host>/sso/login?enterprise_id=<email-domain>&target_url=https://<your-frontend-host>/okta/authenticate
      ```

    * **いいえ** の場合、ユーザーには *「組織は SSO ログイン用に構成されていません。管理者に連絡してください。」* が表示されます。

    `VITE_SSO_ENTERPRISE_ID` はこのモードでは使用されません。複数のドメインが共存できます。各ドメインには、SSO メタデータ タブにアップロードされた独自の IdP メタデータが必要です。
  </Accordion>
</AccordionGroup>

<Info>
  両モードは、同じバックエンドの `/sso/login` エンドポイントと、同じ `enterprise_id` パラメータを使用します。唯一の違いは、その値がフロントエンドの環境変数でハードコードされているか（モード A）、サインイン時にユーザーの電子メールから導出されるか（モード B）です。
</Info>

## バックエンドが `enterprise_id` で行うこと

バックエンドは `GET /sso/login?enterprise_id=acme.com` を受信すると、`acme.com` 用にアップロードされた IdP メタデータを検索し、オンザフライで SAML SP 構成を構築します。

| パラメータ              | 値                                                                                                                                     |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------- |
| **Entity ID**      | デプロイ時に `CUSTOM_ENTITY_ID_FOR_GENERIC_SSO` が設定されている場合はその値。それ以外の場合はデフォルトで `https://<your-backend-host>/user/generic/sso/saml/acs/admin` |
| **ACS エンドポイント**    | `https://<your-backend-host>/user/generic/sso/saml/acs/admin`（HTTP-POST バインディング）                                                      |
| **NameID 形式**      | `emailAddress`                                                                                                                        |
| **リモート IdP メタデータ** | ストレージ内のアップロードされた XML を指す署名付き URL                                                                                                      |

指定された `enterprise_id` のファイルにメタデータが存在しない場合、バックエンドは SAML SP 構成を構築できず、SSO の試行は失敗します。

## ブラウザレベルのリダイレクト チェーン

`enterprise_id` がアップロードされたメタデータに解決されると、認証はブラウザの一連のリダイレクトとして続行されます。

<Steps>
  <Step title="ユーザーがフロントエンドを起動する">
    ユーザーが `https://<your-frontend-host>` で EK を開き、SSO ボタンをクリックします。
  </Step>

  <Step title="フロントエンド → バックエンド">
    フロントエンドはブラウザをバックエンドの SSO エントリ ポイントにリダイレクトします。

    ```
    GET https://<your-backend-host>/sso/login?enterprise_id=acme.com&target_url=https://<your-frontend-host>/okta/authenticate
    ```
  </Step>

  <Step title="バックエンド → IdP">
    バックエンドは、`acme.com` のアップロードされた IdP メタデータから SAML AuthnRequest を構築し、ブラウザを IdP の SSO エンドポイントにリダイレクトします。
  </Step>

  <Step title="IdP がユーザーを認証する">
    IdP が認証を処理します。パスワード、MFA、証明書、または組織が構成した方法を使用します。
  </Step>

  <Step title="IdP → バックエンド">
    IdP は SAML 応答を EK バックエンドの ACS エンドポイントに POST します。

    ```
    POST https://<your-backend-host>/user/generic/sso/saml/acs/admin
    ```

    バックエンドは、アップロードされたメタデータ内の IdP の署名証明書に対してアサーションを検証し、ユーザーを既存の EK アカウントにサインインさせるか、新しいアカウントをプロビジョニングします。
  </Step>

  <Step title="バックエンド → フロントエンド">
    バックエンドはユーザーのブラウザを `<your-frontend-host>` の EK にリダイレクトします。正確な URL は、バックエンドの `FRONTEND_ROOT_URL` 環境変数で決定されます。これが正しく構成されていない場合、ユーザーは SSO を正常に完了したように見えますが、誤ったページに到着します。
  </Step>
</Steps>

<Note>
  IdP は `<your-backend-host>` とのみ通信します。フロントエンド ホストはフローの最初（ユーザーが開始する場所）と最後（サインイン後に到着する場所）に表示されますが、IdP 側の URL には表示されません。
</Note>

SSO を設定する準備はできましたか？詳しい手順については、[SSO メタデータ設定ガイド](/super-admin/sso/saml-sso-metadata-setup-guide) を参照してください。