Auth0 Dashboardのシングルサインオンを構成する

Auth0を構成し、テナントメンバーに自身のエンタープライズIDプロバイダー（IdP）を使用して、シングルサインオン（SSO）を通じてAuth0 Dashboardに認証できるように構成できます。

DashboardのSSOを構成するには、Auth0サポートと連携し、ルートテナント権限（RTA）にエンタープライズ接続を追加する必要があります。これにより、テナントメンバーがDashboardにログインする際に利用可能な認証方法が管理されます。

このSSO接続を追加することは、テナントメンバーが既存の認証方法（メール/パスワード、LinkedIn、Microsoft、GitHub、またはGoogle）を使用してログインすることを制限しません。

DashboardのSSOを構成することで、すべての公開Auth0サイトを有効にします。例：

• Auth0 Webサイト（https://auth0.com）

• Auth0コミュニティ（https://community.auth0.com）

• Auth0のドキュメント（https://www.auth0.com/docs）

• Auth0サポートセンター（https://support.auth0.com）

認可済みユーザーがDashboardのログインに移動すると、Auth0のユニバーサルログインページに登録済みドメインのメールアドレス（例：user@example.com）を入力します。その後、IdPにリダイレクトされ、認証が完了します。

DashboardのSSOの構成を決定する前に、制限について考慮してください。

• SSOは特定のテナントに制限されません。

• SSOはIdP起点認証フローをサポートしません。

• Auth0 Management APIを使用した、テナントメンバーの招待状は、自動化または大量送信ができません。

• テナントメンバーアクセスは、IdPのグループメンバーシップによって管理できません。

• MFAはテナントのすべてのメンバーに強制することはできません。

テナントメンバーがログインできるようにIdPを利用可能な接続として追加すると、IdPのディレクトリの全ユーザーはDashboardにアクセスできるようになります。しかし、特定のテナントに招待されたテナントメンバーのみが、そのテナントにアクセスできます。

招待されていないユーザーがDashboardでテナントにアクセスしようとすると、システムがその操作を拒否します。ユーザーがどのテナントにも属していない場合は、システムがユーザーにユーザープロファイルの完成と新しいトライアルテナントの作成を求めます。新たに作成されたトライアルテナントは、エンタープライズプランには関連付けられません。

新しい接続で作成されたものとは異なるIDを使用して、Dashboardのテナントにテナントメンバーが招待された場合（アクセスも持つ場合）、依然として技術的にそのIDを使用してテナントにアクセスできます。

古いIDを削除するか、潜在的な代替の認証方法として保持するか決めなければなりません。

Dashboardに対するSSOを構成するには、お客様とAuth0サポートの間で共有された一連の手順が必要です。

Auth0サポートを使用してチケットを開くことで、IdPの構成データを共有することができ、そうすることでSSO構成をセットアップすることができます。チケットを提出する際に以下の情報を含めてください。

• SSO構成に関連付けたいメールドメイン

• IdPの名前

• 認証プロトコル

• IdP固有の追加情報

使用したいIdPと認証プロトコルに応じて、追加の構成手順が必要です。

1. 次のプロパティで証明書利用者の信頼を作成します：

   プロパティ	値
   エンティティID	urn:auth0:auth0:{assignedConnectionName}
   コールバックエンドポイント	https://auth0.auth0.com/login/callback

2. 以下の各クレームに対するクレームの説明を追加します：

   クレーム	クレーム識別子	値
   Name Identifier（名前識別子）	http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier	E-Mail-AddressesまたはUser-Principal-Name
   Email Address（メールアドレス）	http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress	該当なし
   Name（名前）	http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name	該当なし

3. SAML 2.0エンドポイントを有効にします。

4. Auth0サポートに以下の情報を提供します：

   • ログインエンドポイント（例：https://{yourServer}/adfs/ls）

   • 署名証明書、またはSAMLメタデータXMLファイル

1. 新しいアプリ登録を作成します。

2. Webに［Redirect URI（リダイレクトURI）］タイプを設定し、https://auth0.auth0.com/login/callbackに値を入力します。

3. ［Register（登録）］を選択します。

4. IDトークンの暗黙的付与を有効化します。

5. IDトークンにメールクレームを追加します。

6. Auth0サポートに以下の情報を提供します：

   • アプリケーション（クライアント）ID

   • OIDCメタデータエンドポイント（例：https://login. microsoftonline.com/{yourAzureAdTenantId}/v2.0/.well-known/openid-configuration）。

1. 新しいエンタープライズアプリケーションを作成します。

2. 以下のプロパティでSAMLのシングルサインオンをセットアップします（Auth0サポートがSSO接続名を提供するまでプレースホルダー値を使用する必要があるかもしれません）。

   プロパティ	値
   識別子（エンティティID）	urn:auth0:auth0:{assignedConnectionName}
   返信（ACS）URL	https://auth0.auth0.com/login/callback
   サインオンURL	https://manage.auth0.com/login?connection={assignedConnectionName}

3. ［Attributes & Claims（属性とクレーム）］セクションでは、email、Unique User Identifier、name - （任意）を含む項目をAzureの推奨設定のまま変更しないでください。

4. Auth0サポートにSAMLメタデータXMLデータを提供します。次のいずれかを実行できます：

   • アプリのフェデレーションメタデータURLを共有します（例：https://login.microsoftonline.com/{azureAdTenantId}/federationmetadata /2007-06/federationmetadata.xml?appid={appId}）。

   • フェデレーションメタデータXMLドキュメントをダウンロードし、チケットに添付します。

Auth0は、Google SAML IdPでDashboardのSSO構成をサポートしますが、既存のGoogle認証方法でユーザーをログインにダイレクトすることを推奨しています。

ユーザーがGoogle SAML IdPにログインする場合、わかりにくいですが、Auth0は、そのために新しいユーザーIDを作成します（既存のGoogleユーザーIDとは別）。

Google SAML IdPでDashboardのSSOをセットアップしたい場合、「ジェネリックIdP（SAML）」をお読みください。

1. 以下のプロパティでSAMLアプリケーションを作成します（Auth0サポートがSSO接続名を提供できるまで、プレースホルダー値を使う必要があるかもしれません）。

   プロパティ	値
   エンティティID	urn:auth0:auth0:{assignedConnectionName}
   コールバックエンドポイント（ACS URL）	https://auth0.auth0.com/login/callback

2. ［Name Identifier（名前ID）］を設定し、ユーザーのメールアドレスを送ります。

3. Auth0サポートにSAMLメタデータXMLデータを提供します。次のいずれかを実行できます：

   • SAMLメタデータXMLURLを共有します：

     1. ［SAML Signing Certificates（SAML署名証明書）］セクションまで移動します。

     2. ［Actions］メニューを選択します。

     3. ［View IdP metadata（IdPメタデータを表示する）］を選択し、その後、［Copy Link Address（リンクアドレスをコピーする）］を選択します。それはこの形式になります：https://{org}.okta.com/app/{appId}/sso/saml/metadata。

   • SAMLメタデータXMLファイルをダウンロードし、チケットに添付します。

DashboardのSSOは、IdP起点認証フローをサポートしません。ユーザーがDashboardにログインする際にチクレットを選択できるようにするには、次の手順が必要です。

1. SAMLアプリがユーザーに表示されないようにします。

2. https://manage.auth0.com/login?connection={assignedConnectionName}を指すブックマークアプリを作成します。これはユーザーがログインを選択できるようになるアプリケーションです。

SAMLアプリケーションとブックマークアプリの両方を、同じユーザーのセットに対して有効にし、アプリケーションを使用できるようにしてください。

1. 以下のプロパティでSAMLのテストコネクター（SP）を作成します（Auth0サポートがSSO接続名を提供できるようになるまで、プレースホルダー値を使用する必要があるかもしれません）。

   プロパティ	値
   エンティティID	urn:auth0:auth0:{assignedConnectionName}
   コールバックエンドポイント（ACS URL）	https://auth0.auth0.com/login/callback
   ログインURL	https://manage.auth0.com/login?connection={assignedConnectionName}

2. Auth0サポートにSAMLメタデータXMLファイルを提供します。

1. 以下のプロパティを使用して、IdPでアプリケーションを登録します。

   プロパティ	値
   Callback URL	https://auth0.auth0.com/login/callback

2. IDトークンにメールクレームを追加します。

3. Auth0サポートに以下を提供します。

   • アプリケーション（クライアント）ID

   • 発行者URL、またはOIDCメタデータエンドポイント（例：https://{idpDomain}/[...]/.well-known/openid-configuration）

1. Auth0サポートは、SSO接続名を提供します。

2. 次のプロパティでSAMLアプリケーションを作成します。

   プロパティ	値
   Entity ID（エンティティID）	urn:auth0:auth0:{assignedConnectionName}
   Callback endpoint（コールバックエンドポイント）	https://auth0.auth0.com/login/callback

3. SAMLアサーションに以下のクレームが含まれているようにしてください。

   クレーム	クレーム識別子	値
   Name Identifier（名前識別子）	http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier	upnまたはemailaddress
   Email Address（メールアドレス）	http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress	該当なし
   Name（名前）	http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name	該当なし

4. Auth0サポートに次のいずれかを提供します。

   • サインインURLと署名証明書

   • SAMLメタデータXMLファイル

Auth0サポートチームは、提供される構成データを使用して、SSO接続の初期設定を完了します。

初期設定時には、ホーム領域検出（Home Realm Discovery：HRD）は構成されていません。

SSO接続の初期設定が完了したら、Auth0サポートチームがSSO接続をテストし、構成データが正しいかを確認します、そして、テナントメンバーが望む方法でSSO接続で認証できることを確認します。

Auth0サポートチームは、新しいSSO接続の認証を促すために使用できる直接ログインURLを提供します。例：

https://manage.auth0.com/login?connection={assignedConnectionName}

エンタープライズテナントでAuth0 Teamsを使用する場合、Teamsアカウントに属するテナントに対してSSO認証を強制できます。テナント登録と管理についての詳細は、「Auth0 Teams」をお読みください。

1. 新しいブラウザーを開き、TeamsアカウントとIDを入力してください。https://accounts.auth0.com/teams/{team-identifier}。

   Teams識別子は、URLまたはTeamsの設定から取得できます。

2. ［Security（セキュリティ）］ページに移動します。

3. ［Enforce Single Sign On（シングルサインオンの強制）］を選択することで、セキュリティポリシーを構成します。

ユニバーサルログインまたはクラシックログインを使用している場合、HRDの有効化を要求できるため、ログインページはテナントメンバーが入力するメールアドレスのドメインを認識し、新しいSSO接続に誘導します。

HRDが有効になっている場合、以前にメール/パスワードのIDを使用していた（構成されたHRDドメインと一致するメールを持つ）テナントメンバーは、ログインページからログインできなくなります。

この動作の変更に伴い、HRDを有効にする際は、現在のテナントメンバーの少なくとも一部が変更について認識していることを確認した上で、以下のいずれかを知っている必要があります。

• 新しいIDの下で、テナントへの参加招待状を受け取る

• 新しいIDで再招待をする必要がある

テナントメンバーがメール/パスワードIDでログインをする必要がある場合、ダイレクトログインURLを提供できます。

https://manage.auth0.com/login?connection=auth0

このURLはHRDをバイパスし、メール/パスワードIDでログインできるようにします。

次に、テナントメンバーのリストの例を示します。

example.comドメインを新しい接続に関連付けた場合、user1@gmail.com、user2@example.com、およびuser3@acme.comは、ソーシャルプロバイダー、または関連付けられていないドメインのメールアドレスを使用しているため、これまでと同様にログインできます。

一方で、user1@example.com、user4@example.com、およびuser5@example.comは、HRDに構成されたドメインに関連付けられたメールアドレスであるため、これまでのようにログインすることはできません。

既存のテナントメンバーの移行プロセスは、HRDを有効にしたかどうかに依存します。

HRDが無効の状態でテナントメンバーを移行するには、新しいSSO接続に対してダイレクトログインURLを共有する必要があります。

https://manage.auth0.com/login?connection={assignedConnectionName}

1. テナントメンバーに対して、新しいテナントメンバー招待状を作成します。

2. テナントメンバーに以下を行うように指示します。

   1. 招待状を受け入れる前に、ダイレクトログインURLを使用することで、新しいSSO接続にログインします。これが新しいSSO接続への初めてのログインである場合、ユーザープロファイリングを完了する必要があるかもしれません。

   2. 招待メールに記載されている招待状URLを、新しいSSO接続でログインしたのと同じブラウザーにコピーして貼り付けます。ユーザーは［Create Account（アカウントの作成）］を選択しないでください。

   3. 招待状を受け入れます。

   4. ユーザーが別のテナントに招待されている場合は、このときにそれを使用できます。

HRDを有効にした状態でテナントメンバーを移行するには、テナントメンバーの追加に類似した手順を追う必要があります。

1. テナントメンバーに対して、新しいテナントメンバー招待状を作成します。

2. テナントメンバーに以下を行うように指示します。

   1. Dashboardからログアウします（以前に古いIDでログインしたことがある場合）。

   2. 受け取った招待メールにある招待状リンクを開きます。

   3. 新しい接続にログインします。

   4. 招待状を受け入れます。