メインコンテンツへスキップ

EK の SAML 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.

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 つのシステム間で相互の信頼を交換する必要があります。認証が行われる前に、双方が相手が誰であるかを知る必要があります。

Service Provider (SP) — EK

お客様のオンプレミス EK インスタンスです。EK は SP メタデータを公開し、IdP が SAML 応答を送信すべき場所、使用する NameID 形式、および AuthnRequests で信頼すべき署名証明書を確認できるようにします。

Identity Provider (IdP) — お客様の組織

組織の Okta、Entra ID、Ping、ADFS などです。IdP は、発行者、SSO エンドポイント、署名証明書を記述するメタデータ XML を公開します。EK は IdP が返すアサーションを検証するためにこれを必要とします。

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

  1. IdP と SP メタデータを共有する

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

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

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

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

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

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

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

モード 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 メタデータが必要です。

情報

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

バックエンドが 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 がアップロードされたメタデータに解決されると、認証はブラウザの一連のリダイレクトとして続行されます。

  1. ユーザーがフロントエンドを起動する

    ユーザーが https://<your-frontend-host> で EK を開き、SSO ボタンをクリックします。

  2. フロントエンド → バックエンド

    フロントエンドはブラウザをバックエンドの SSO エントリ ポイントにリダイレクトします。

    GET https://<your-backend-host>/sso/login?enterprise_id=acme.com&target_url=https://<your-frontend-host>/okta/authenticate
  3. バックエンド → IdP

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

  4. IdP がユーザーを認証する

    IdP が認証を処理します。パスワード、MFA、証明書、または組織が構成した方法を使用します。

  5. IdP → バックエンド

    IdP は SAML 応答を EK バックエンドの ACS エンドポイントに POST します。

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

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

  6. バックエンド → フロントエンド

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

注意

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

SSO を設定する準備はできましたか？詳しい手順については、SSO メタデータ設定ガイド を参照してください。