> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arc.cdata.com/llms.txt
> Use this file to discover all available pages before exploring further.
# SSO とユーザープロビジョニング
> Microsoft Entra ID やOkta との統合を含む、CData Arc でSAML 2.0 またはOpenID Connect 経由のシングルサインオンを設定する方法。
export const siteNameShort = "Arc";
export const siteName = "CData Arc";
{siteName} は、SAML 2.0 またはOpenID 認証プロトコルによるシングルサインオン（SSO）をサポートします。この機能により、これらのプロトコルをサポートするMicrosoft Entra ID（旧 Azure Active Directory）やOkta などのID プロバイダーが、{siteNameShort} のSSO プラットフォームとして機能します。
## 概要
SSO を有効にするには、**設定**ページの**セキュリティ**タブで項目を設定する必要があります。SSO を設定する場合、{siteNameShort} で作成されたユーザーにはフェデレーション識別子（ID）を付与する必要があります。このフェデレーションID は、{siteNameShort} のユーザー名とID プロバイダーエンティティを関連付けます。{siteNameShort} ユーザーがアプリケーションにログインしようとすると、SSO プラットフォームにリダイレクトされ、そこで適切なID の資格情報を入力する必要があります。
ジャストインタイム（JIT）ユーザープロビジョニングが有効になっている場合（**セキュリティ**タブからも設定可能）は、ID プロバイダーから受け取った属性（ユーザーの氏名やE メールアドレスなど）に基づいて、ログイン時に新しいユーザーアカウントが{siteNameShort} に自動的に作成されます。このアイデンティティとアクセス管理（IAM）プロセスは、手動でのアカウント作成の必要性を排除し、オンボーディングを合理化します。詳しくは、[ジャストインタイム（JIT）ユーザープロビジョニング](#ジャストインタイム-jit-ユーザープロビジョニング)を参照してください。
SSO が設定され、{siteNameShort} ユーザーがID プロバイダーと関連付けるためのフェデレーションID 値を取得したら、次のセクションで説明するとおり、SSO ユーザー管理のための追加の詳細設定はSSO プラットフォームで直接実行する必要があります。
* SSO が有効になると、[Admin ロール](./user-roles#admin-ロール)のメンバーでない既存ユーザーは、アカウントにフェデレーションId（後述）が設定されていない限りログインできません。Admin ユーザーは、SSO の設定を再構成する必要がある場合に備え、SSO なしでもログインできます。
* 現在、{siteNameShort} は個人ユーザーのみサポートしており、ユーザーグループはサポートしていません。SSO プラットフォームがユーザーグループへのアクセスを提供する場合、グループ内の個々のユーザーは、ログインするために{siteNameShort} の**設定**ページでユーザーとして追加される必要があります。各ユーザーは、ID プロバイダーからのフェデレーションID を参照する必要があります。
次のセクションでは、OpenID Connect およびSAML 2.0 認証プロトコルを使用して、2つのID プロバイダー（Microsoft Entra ID およびOkta）でSSO 構成を設定する方法について説明します。
## SSO の設定
このセクションでは、SSO の各設定と、それらが{siteNameShort} で何を意味するかについて説明します。これらの設定の詳細は、IdP によって異なる場合があります。
### OpenID Connect の設定
| 設定 | 説明 |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **コールバックURL** | コールバックURL は（{siteNameShort} ではなく）IdP で設定され、ユーザーがIdP に対して認証を実行した後に返される場所を示します。 |
| **OAuth クライアントId** | IdP で作成されるOAuth アプリケーションに関連付けられたクライアントId。 |
| **OAuth クライアントシークレット** | IdP で作成されるOAuth アプリケーションに関連付けられたクライアントシークレット。 |
| **オーディエンスURI** | SSO ログイントークンの意図された受信者。これは、SSO プラットフォームによって生成されたトークンが、{siteNameShort} での使用を目的としていることを保証します。この値を、SSO プラットフォームで{siteNameShort} を信頼できるアプリケーションとして識別するURI に設定します（例えば、SSO プラットフォームが{siteNameShort} 用に生成した *Application Id* など）。複数のURI に対応するには、カンマ区切りリストを指定します。 |
| **ディスカバリーURL** | SSO プロバイダーから設定をインポートする必要があります。 |
| **発行者証明書** | IdP がJWT トークンで署名するために使用する証明書の公開部分。これは、要求を受けたIdP によって生成されたトークンのみが受け入れられることを保証するのに役立ちます。 |
| **トークン発行者識別子** | IdP がJWT トークンを生成するために使用する識別子。{siteNameShort} は、トークンがこの識別子を含むことを確認するために検証します。これは、要求を受けたIdP によって生成されたトークンのみが受け入れられることを保証するのに役立ちます。 |
| **認可URL** | ユーザーがIdP を経由して認可を実行する必要があるURL。SSO ユーザーが{siteNameShort} にログインしようとすると、アプリケーションはユーザーをこのURL にリダイレクトし、そこでSSO プラットフォームの資格情報を入力します。 |
| **トークンURL** | IdP から安全な認証トークンを取得することができるURL。 |
| **ログオフURL** | アプリケーションからログアウトした後の{siteNameShort} ユーザーのリダイレクト先を指定します。 |
| **デフォルトスコープ** | IdP に要求するスコープ（アクセス許可のセット）のスペース区切りのリスト。通常、スコープには、ID 検証を要求するために少なくとも`profile openid` を含める必要があります。 |
| **Key Claim** | フェデレーションId として扱うIdP からの値。言い換えると、ユーザーをIdP から{siteNameShort} のユーザー名にマッピングする際にフェデレーションID として使用するクレームを指定します。 |
| **トークン署名アルゴリズム** | 署名されたJWT トークンからどの署名アルゴリズムを受け入れるか。署名のないトークンは認められません。 |
| **ジャストインタイム（JIT）プロビジョニング** | ユーザーが初めてログインしたときに、{siteNameShort} に新しいユーザーアカウントを自動的に作成するかどうか。ユーザーの詳細は、クレームで提供された属性に基づきます。 |
| **デフォルトロール** | JIT プロビジョニング中に作成されたアカウントに割り当てられる[ロール](./user-roles)（Support、Standard、またはAdmin）。**デフォルトロールなし**を選択した場合は、クレームで指定されたロールが使用されます。 |
### SAML 2.0 の設定
| 設定 | 説明 |
| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| **アサーションコンシューマサービス（ACS）URL** | ユーザーが正常にログインした後にIdP がSAML 認証応答を送信する{siteNameShort} アプリケーションのエンドポイント。これは、OpenID のコールバックURL 設定に似ています。 |
| **オーディエンスURI** | SAML アサーションの送信先となる一意の識別子（通常はアプリケーションのエンティティID）。応答がアプリケーション向けであることを検証するために使用されます。 |
| **SAML ディスカバリーURL** | 認証に使用するIdP を決定するために使用されるエンドポイント。SSO プロバイダーから設定をインポートする必要があります。 |
| **発行者証明書** | IdP がJWT トークンで署名するために使用する証明書の公開部分。要求を受けたIdP によって生成されたトークンのみが受け入れられることを保証するのに役立ちます。 |
| **エンティティID** | SAML 認証プロセスでIdP またはサービスプロバイダーを識別するために使用される、グローバルに一意の識別子（多くの場合、URI 形式）。 |
| **SSO URL** | サービスプロバイダーがユーザーをリダイレクトしてSAML 認証フローを開始するIdP エンドポイント。 |
| **ログオフURL** | アプリケーションからログアウトした後の{siteNameShort} ユーザーのリダイレクト先を指定します。 |
| **ジャストインタイム（JIT）プロビジョニング** | ユーザーが初めてログインしたときに、{siteNameShort} に新しいユーザーアカウントを自動的に作成するかどうか。ユーザーの詳細は、SAML アサーションで提供された属性に基づきます。 |
| **デフォルトロール** | JIT プロビジョニング中に作成されたアカウントに割り当てられる[ロール](./user-roles)（Support、Standard、またはAdmin）。**デフォルトロールなし**を選択した場合は、SAML アサーションで指定されたロールが使用されます。 |
## Microsoft Entra ID のSSO 設定
次のセクションでは、OpenID Connect またはSAML 2.0 経由でSSO 用にMicrosoft Entra ID を設定する方法について説明します。
### OpenID Connect 設定
Microsoft Entra ID を使用したシングルサインオン（SSO）により、{siteName} へのアクセスが合理化され、ログイン時にジャストインタイムのプロビジョニングが可能になります。次の手順では、OpenID Connect プロトコルを使用してSSO 用にMicrosoft Entra ID を設定する方法について説明します。
1. Azure ポータルにログインし、Microsoft Entra ID を開きます。
2. {siteName} にログインし、**設定 > SSO** を選択して**シングルサインオン（SSO）設定**ダイアログボックスを開きます。
3. **Entra ID > アプリ登録 > 新規登録**に移動し、{siteNameShort} のアプリケーション登録を作成します。プロンプトに従って処理を完了します。
4. アプリ登録で、リダイレクトURL を、以下に示すように{siteNameShort} の**シングルサインオン（SSO）設定**ダイアログボックスで指定されている**コールバックURL** 値に設定します。
5. {siteNameShort} の**シングルサインオン（SSO）設定**ダイアログボックスで、次のプロパティを指定します：
1. **クライアントID** プロパティを、以下に示す新しいアプリ登録にある**アプリケーション（クライアント）Id** の値に設定します。
2. **クライアントシークレット**プロパティを、アプリ登録の**クライアントクレデンシャル**セクションで作成した新しいクライアントシークレットの値に設定します。
3. **ディスカバリーURL** を、アプリ登録の**エンドポイント**ページにある**OpenID Connect MetaData document** の値に設定します。次に、**インポート**をクリックして、残りの設定を{siteNameShort} にインポートします。
6. {siteNameShort} で**保存およびテスト**をクリックして、SSO の設定を確認します。{siteNameShort} で新しいタブが開き、Microsoft アカウントでのサインインを求められます。テストに成功すると、{siteNameShort} はクレームの詳細とともに成功メッセージを表示します。
7. （オプション）{siteNameShort} ユーザーアカウントをフェデレーションId で更新します。
1. ステップ5 の**シングルサインオン（SSO）設定**ダイアログボックスから、フェデレーションId をコピーします。
2. **設定 > ユーザー**に移動します。次に、ユーザーアカウントを見つけて**編集**をクリックします。
3. ユーザーアカウントにフェデレーションId を追加します。次に、**保存**をクリックして変更を保存し、ダイアログボックスを終了します。
この時点で、OpenID Connect SSO の基本設定が完了し、ユーザーはMicrosoft Entra ID 経由で{siteNameShort} にログインできるようになりました。
### SAML 2.0 設定
SAML ベースのシングルサインオン（SSO）により、ユーザーは組織のID プロバイダーを通じてシームレスに認証できるため、ログイン時にジャストインタイムプロビジョニングが可能になります。次の手順では、SAML 2.0 プロトコルを使用してSSO 用にMicrosoft Entra ID を設定する方法について説明します。
1. Azure ポータルにログインしてMicrosoft Entra ID を開き、**エンタープライズ アプリケーション**ページに移動します。
2. **新しいアプリケーション > 独自のアプリケーションを作成する**を選択します。**独自のアプリケーションを作成する**ダイアログボックスで：
1. アプリケーションの名前を入力します（例：**CData Arc**）。
2. **アプリケーションでどのような操作を行いたいですか？** の下にあるオプションから、アプリケーションで実行したい操作を指定します。
3. **作成**をクリックします。
3. 新規作成したアプリケーションで、**シングルサインオンの設定**を選択します。
4. サインオン方式として**SAML** を選択します。
5. {siteName} にログインし、**設定 > SSO** を選択します。**SSO** タブで、**シングルサインオン（SSO）設定**セクションの**設定**をクリックします。このアクションにより、**シングルサインオン（SSO）設定**ダイアログボックスが開きます。
6. **SAML 2.0** を選択します。これを選択すると、アサーションコンシューマーサービス（ACS）URL とオーディエンスURI が表示されます。
このダイアログボックスは、手順の後半で再び必要になるので開いたままにしておきます。
7. Entra ID で、**応答URL（アサーションコンシューマーサービスURL）** を{siteNameShort} の**アサーションコンシューマーサービス（ACS）URL** 値に設定します。次に、Entra ID の**識別子（エンティティID）** を、{siteNameShort} の**オーディエンスURI** 値に設定します。
ID プロバイダーによるサインオンを使用する場合は、**サインオンURL** テキストボックスを空のままにしておきます。
8. {siteNameShort} の**シングルサインオン（SSO）設定**ダイアログボックスで、**ディスカバリーURL** を、Entra ID にある**App Federation Metadata URL** 値に設定します。次に、**インポート**をクリックして、残りの設定を{siteNameShort} にインポートします。
9. {siteNameShort} で**保存およびテスト**をクリックして、SSO の設定を確認します。{siteNameShort} で新しいタブが開き、Microsoft アカウントでのサインインを求められます。テストに成功すると、{siteNameShort} はクレームの詳細とともに成功メッセージを表示します。
[.NET 版](../../installation/windows-edition)を使用している場合は、テストに影響する可能性のある.NET の問題については、[.NET におけるSAML 2.0 設定の既知の問題](#net-におけるsaml-2-0-設定の既知の問題)を参照してください。
10. （オプション）{siteNameShort} ユーザーアカウントをフェデレーションId で更新します。
1. ステップ9 の**シングルサインオン（SSO）設定**ダイアログボックスからフェデレーションId をコピーします。
2. **設定 > ユーザー**に移動します。次に、ユーザーアカウントを見つけて**編集**をクリックします。
3. ユーザーアカウントにフェデレーションId を追加します。次に、**保存**をクリックして変更を保存し、ダイアログボックスを終了します。
この時点で、SAML SSO の基本設定が完了し、ユーザーはMicrosoft Entra ID 経由で{siteNameShort} にログインできるようになりました。
## Okta のSSO 設定
次のセクションでは、OpenID Connect またはSAML 2.0 経由でSSO 用にOkta を設定する方法について説明します。
### OpenID Connect 設定
Okta を使用したシングルサインオン（SSO）により、{siteName} へのアクセスが合理化され、ログイン時にジャストインタイムのプロビジョニングが可能になります。次の手順では、OpenID Connect プロトコルを使用してSSO 用にOkta を設定する方法について説明します。
1. Okta 管理コンソールにログインし、**Applications > Applications > Create App Integration** を選択します。
2. **新しいアプリ統合の作成**ダイアログボックスで、**サインイン方式**に**OIDC - OpenID Connect** を、**アプリケーションの種類**に**Web アプリケーション**を選択します。続いて、**次へ**をクリックします。
3. {siteName} にログインし、**設定 > SSO** を選択して**シングルサインオン（SSO）設定**ダイアログボックスを開きます。
4. Okta で、リダイレクトURI を、以下に示すように{siteNameShort} の**シングルサインオン（SSO）設定**ダイアログボックスで指定されている**コールバックURL** 値に設定します。
続いて、**次へ**をクリックしてアプリケーションを作成します。
5. 以下のように、発行者URL を検索してコピーします。
1. Okta 管理コンソールで、アプリケーションの**Sign-On** タブをクリックします。
2. **OpenID Connect ID Token** セクションまでスクロールします。
3. **Issuer** フィールドからURL をコピーします。
認可サーバー経由でサインインする場合は、その特定のサーバーの発行者URL を取得する必要があります。Okta 管理コンソールで、左側のナビゲーションペインの**Security** をクリックし、**API** を選択して**Authorization Servers** リストを表示します。認可サーバーを見つけて、**Issuer** フィールドからURL をコピーします。
6. {siteNameShort} の**シングルサインオン（SSO）設定**ダイアログボックスで、次のプロパティを指定します：
1. **クライアントID** および**クライアントシークレット**プロパティを、Okta の**全般**タブにある対応する値に設定します。
2. **ディスカバリーURL** を、先ほどコピーした発行者URL に設定し、OpenID Connect ディスカバリーエンドポイント（`.well-known/openid-configuration`）を追加します。
**例：** `https://MyOrganization.okta.com/.well-known/openid-configuration`
次に、**インポート**をクリックして、残りの設定を{siteNameShort} にインポートします。
7. {siteNameShort} で**保存およびテスト**をクリックして、SSO の設定を確認します。{siteNameShort} で新しいタブが開き、Okta アカウントでのサインインを求められます。テストに成功すると、{siteNameShort} はクレームの詳細とともに成功メッセージを表示します。
8. （オプション）{siteNameShort} ユーザーアカウントをフェデレーションId で更新します。
1. ステップ6 の**シングルサインオン（SSO）設定**ダイアログボックスから、フェデレーションId をコピーします。
2. **設定 > ユーザー**に移動します。次に、ユーザーアカウントを見つけて**編集**をクリックします。
3. ユーザーアカウントにフェデレーションId を追加します。次に、**保存**をクリックして変更を保存し、ダイアログボックスを終了します。
この時点で、OpenID Connect SSO の基本設定が完了し、ユーザーはOkta 経由で{siteNameShort} にログインできるようになりました。
### SAML 2.0 設定
SAML ベースのシングルサインオン（SSO）により、ユーザーは組織のID プロバイダーを通じてシームレスに認証できるため、ログイン時にジャストインタイムプロビジョニングが可能になります。次の手順では、SAML 2.0 プロトコルを使用してSSO 用にOkta を設定する方法について説明します。
1. Okta 管理コンソールにログインし、**Applications > Create App Integration** を選択します。この手順により、**新しいアプリ統合の作成**ダイアログボックスが開きます。
2. サインイン方式として**SAML 2.0** を選択します。続いて、**次へ**をクリックすると**SAML 統合の作成**ダイアログボックスが開きます。
3. **アプリ名**テキストボックスに、アプリケーションのわかりやすい名前（例えば、**{siteName}**）を入力します。必要に応じて、アプリケーションのロゴを追加することもできます。続いて、**次へ**をクリックします。
4. {siteNameShort} アプリケーションで、**設定**ページの**SSO**タブをクリックします。そのタブ上で、**シングルサインオン（SSO）設定**セクションの**設定**をクリックします。このアクションにより、**シングルサインオン（SSO）設定**ダイアログボックスが開きます。
5. **SAML 2.0** を選択します。これを選択すると、アサーションコンシューマーサービス（ACS）URL とオーディエンスURI が表示されます。
このダイアログボックスは、手順の後半で再び必要になるので開いたままにしておきます。
6. Okta で、{siteNameShort} の**アサーションコンシューマーサービス（ACS）URL** 値を、**シングルサインオンURL** テキストボックスに入力します。次に、{siteNameShort} の**オーディエンスURI** 値を**オーディエンスURI（SP エンティティID）** テキストボックスに入力します。残りのOkta フィールドは、デフォルト設定のままにしておきます。
7. {siteNameShort} で、**ディスカバリーURL** を、登録済みのOkta 組織のドメインに`/oauth2/default/.well-known/openid-configuration` を付けたURL に設定します。
**例：** `https://trial-1234567.okta.com/oauth2/default/.well-known/openid-configuration`
次に、**インポート**をクリックして、残りの設定を{siteNameShort} にインポートします。
8. {siteNameShort} で**保存およびテスト**をクリックして、SSO の設定を確認します。{siteNameShort} で新しいタブが開き、Okta アカウントでのサインインを求められます。テストに成功すると、{siteNameShort} はクレームの詳細とともに成功メッセージを表示します。
[.NET 版](../../installation/windows-edition)を使用している場合は、テストに影響する可能性のある.NET の問題については、[.NET におけるSAML 2.0 設定の既知の問題](#net-におけるsaml-2-0-設定の既知の問題)を参照してください。
9. （オプション）{siteNameShort} ユーザーアカウントをフェデレーションId で更新します。
1. ステップ8 の**シングルサインオン（SSO）設定**ダイアログボックスから、フェデレーションId をコピーします。
2. **設定 > ユーザー**に移動します。次に、ユーザーアカウントを見つけて**編集**をクリックします。
3. ユーザーアカウントにフェデレーションId を追加します。次に、**保存**をクリックして変更を保存し、ダイアログボックスを終了します。
この時点で、SAML SSO の基本設定が完了し、Okta 経由で{siteNameShort} にログインできるようになりました。
## ジャストインタイム（JIT）ユーザープロビジョニング
[前述](#概要)のとおり、*ジャストインタイムユーザープロビジョニング* により、{siteNameShort} はID プロバイダーから提供された情報を使用して、初回ログイン時にユーザーアカウントを自動的に作成および管理できるようになります。JIT プロビジョニングは、ユーザーが初めてID プロバイダーを通じて{siteNameShort} にアクセスし、アプリケーションがユーザーのID を確認する安全なメッセージを受信する場合に特に便利です。作成されたアカウントには、SSO 設定で指定されたデフォルトのロールが割り当てられます。この機能により、ユーザーのオンボーディングが合理化され、アカウントの詳細がアイデンティティクレームと一致することが保証されます。
ユーザーがSAML またはOpenID Connect を使用して{siteNameShort} にログインすると、{siteNameShort} はフェデレーションId を介してそのユーザーを検索します。
* ユーザーが**存在しない**場合、{siteNameShort} は認証クレームで提供される情報を使用して新しいユーザーを自動的に作成します。
* ユーザーが**存在する**場合、{siteNameShort} は、クレーム値と一致しない場合にユーザーのユーザー名とE メールアドレスを更新します。
### ID プロバイダーにおける要件とマッピング
ID プロバイダーの要件は、SAML 2.0 またはOpenID Connect のどちらを使用するかによって異なります。このセクションでは、各認証方式のクレーム要件について説明します。
**OpenID Connect**
* デフォルトでは、サブコントロールはユーザーのロールにマッピングされ、クレームはフェデレーションId にマッピングされます。オプションとして、**admin** ユーザーは、{siteNameShort} で**Key Claim** プロパティを設定することにより、別のフィールド（例えば**oid**）を使用できます。
* **Email** クレームは、{siteNameShort} の**Email Address** にマッピングされます。
* **preferred\_username** クレームは、{siteNameShort} の**name** にマッピングされます。
**SAML 2.0**
* **NameID** と**Email** クレームは必須です。
* （オプション）**Name** クレームを追加できます。これは、{siteNameShort} の**Username** にマッピングされます。
* （オプション）**Role** クレームを追加できます。これは、ユーザーのロールを制御します。
### Arc でのJIT 設定
{siteNameShort} でJIT プロビジョニングを有効化および設定するには：
1. 次の手順でJIT プロビジョニングを有効にします：
1. {siteNameShort} で**設定 > SSO** を選択します。
2. タブレットと鉛筆 
アイコンをクリックし、**ジャストインタイム（JIT）プロビジョニング**ダイアログボックスを開きます。
3. **JIT プロビジョニング**カテゴリの下で**有効化**を選択します。
4. （オプション）**デフォルトロール**リストからロールを選択して、デフォルトのロールを設定します。
5. **保存**をクリックして選択内容を保存し、ダイアログボックスを終了します。
ユーザーがログインすると、{siteNameShort} は次の順序でロールを調整します：
1. クレームにロールが含まれている場合、{siteNameShort} はそのロールを検索してユーザーアカウントを更新します。
2. ロールクレームが存在しないか無効な場合、{siteNameShort} は設定されたデフォルトロールを使用します。これは、ID プロバイダーによってクレームでロールが割り当てられない限り、JIT を使用してデフォルトロールで作成されたユーザーのロールは、{siteNameShort} のadmin ユーザーによって上書きできないことを意味します。
3. デフォルトロールが設定されていない場合、ユーザーアカウントにはロールがないため、**Admin** ユーザーが手動でユーザーのロールを更新する必要があります。
## .NET におけるSAML 2.0 設定の既知の問題
.NET 版でSAML 2.0 を設定する場合、**保存およびテスト**ボタンをクリックすると認証が成功したように見えても、その後にエラーが表示されます。これは既知の.NET プラットフォームの問題であり、実際のSAML ログインには影響しません。
SameSite クッキーの制限を緩和すると、クロスサイトリクエストフォージェリ（CSRF）攻撃にさらされるリスクが高まる可能性があるため、これらの設定はデフォルトではWeb.Config に含まれていません。この回避策を有効にすると、より厳格なデフォルトのセキュリティと引き換えに、.NET の特定のSAML 2.0 ログインフローとの互換性が得られます。
この問題を回避するには、次の手順に従います：
1. 次の内容をWeb.Config ファイルに追加します（デフォルトでは、ファイルはC:\Program Files\CData\CData Arc\www にあります）：
* `authentication mode="forms"` 内の`cookieSameSite="None" requireSSL="true"`
* `httpCookies` 内の`sameSite="None" requireSSL="true"`
* `sessionState` 内の`cookieSameSite="None" cookieless="UseCookies"`
2. HTTPS でArc を再起動します。
このサンプルのWeb.Config ファイルは、必要な更新内容を示しています：
```xml theme={null}
```