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.
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 つのフロントエンド環境変数によって異なります。モード A — シングルクリック SSO（VITE_ALLOW_ONLY_SSO_LOGIN=true）
モード A — シングルクリック SSO（VITE_ALLOW_ONLY_SSO_LOGIN=true）
ログイン画面には SSO ボタンのみが表示され、電子メール アドレスやパスワードのフィールドは表示されません。これは、単一の電子メール ドメインにサービスを提供するオンプレミス展開の一般的なセットアップです。ユーザーがボタンをクリックすると、フロントエンドは これを機能させるには:
VITE_SSO_ENTERPRISE_ID を読み取り、すぐに次の場所にリダイレクトします。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、デフォルト）
モード B — 電子メールモーダル SSO（VITE_ALLOW_ONLY_SSO_LOGIN=false、デフォルト）
ログイン画面には、電子メール/パスワードと SSO コントロールが一緒に表示されます。SSO ボタンをクリックすると、「電子メールを入力してください」 モーダルが開きます。ユーザーが電子メールを送信した後、フロントエンドはドメインを抽出し、
POST https://<your-backend-host>/sso/verify_enterprise_id 経由でバックエンドが SSO を構成しているかどうかを確認します。-
はい の場合、フロントエンドは以下にリダイレクトします。
- いいえ の場合、ユーザーには 「組織は 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 構成を構築します。
指定された
enterprise_id のファイルにメタデータが存在しない場合、バックエンドは SAML SP 構成を構築できず、SSO の試行は失敗します。
ブラウザレベルのリダイレクト チェーン
enterprise_id がアップロードされたメタデータに解決されると、認証はブラウザの一連のリダイレクトとして続行されます。
1
ユーザーがフロントエンドを起動する
ユーザーが
https://<your-frontend-host> で EK を開き、SSO ボタンをクリックします。2
フロントエンド → バックエンド
フロントエンドはブラウザをバックエンドの SSO エントリ ポイントにリダイレクトします。
3
バックエンド → IdP
バックエンドは、
acme.com のアップロードされた IdP メタデータから SAML AuthnRequest を構築し、ブラウザを IdP の SSO エンドポイントにリダイレクトします。4
IdP がユーザーを認証する
IdP が認証を処理します。パスワード、MFA、証明書、または組織が構成した方法を使用します。
5
IdP → バックエンド
IdP は SAML 応答を EK バックエンドの ACS エンドポイントに POST します。バックエンドは、アップロードされたメタデータ内の IdP の署名証明書に対してアサーションを検証し、ユーザーを既存の EK アカウントにサインインさせるか、新しいアカウントをプロビジョニングします。
6
バックエンド → フロントエンド
バックエンドはユーザーのブラウザを
<your-frontend-host> の EK にリダイレクトします。正確な URL は、バックエンドの FRONTEND_ROOT_URL 環境変数で決定されます。これが正しく構成されていない場合、ユーザーは SSO を正常に完了したように見えますが、誤ったページに到着します。IdP は
<your-backend-host> とのみ通信します。フロントエンド ホストはフローの最初（ユーザーが開始する場所）と最後（サインイン後に到着する場所）に表示されますが、IdP 側の URL には表示されません。