> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sync.cdata.com/llms.txt
> Use this file to discover all available pages before exploring further.
# シングルサインオン
export const siteNameShort = "Sync";
export const siteName = "CData Sync";
{siteName} は、SAML 2.0 またはOpenID 認証プロトコルによるシングルサインオン（SSO）をサポートします。この機能により、これらのプロトコルをサポートするMicrosoft Entra ID（旧 Azure Active Directory）やOkta などのID プロバイダーが、{siteNameShort} のSSO プラットフォームとして機能します。
## 概要
SSO を有効にするには、**設定**ページの**SSO** タブで項目を設定する必要があります。SSO を設定する場合、{siteNameShort} で作成されたユーザーにはフェデレーション識別子（ID）を付与する必要があります。このフェデレーションID は、{siteNameShort} のユーザー名とID プロバイダーエンティティを関連付けます。{siteNameShort} ユーザーがアプリケーションにログインしようとすると、SSO プラットフォームにリダイレクトされ、そこで適切なID の資格情報を入力する必要があります。
ジャストインタイム（JIT）ユーザープロビジョニングが有効になっている場合（**SSO** タブからも設定可能）は、ID プロバイダーから受け取った属性（ユーザーの氏名やE メールアドレスなど）に基づいて、ログイン時に新しいユーザーアカウントが{siteNameShort} に自動的に作成されます。このアイデンティティとアクセス管理（IAM）プロセスは、手動でのアカウント作成の必要性を排除し、オンボーディングを合理化します。詳しくは、[ジャストインタイム（JIT）ユーザープロビジョニング](#just-in-time-jit-user-provisioning)を参照してください。
After SSO is configured and {siteNameShort} users have a federation Id value to associate them with an identity provider (IdP), you can perform additional configuration either in Sync (for example, enabling JIT provisioning) or directly in the IdP, as explained in later sections.
{siteNameShort} supports group-based access via the group-to-role mapping feature in JIT provisioning. You can map group identifiers that are provided by the IdP to {siteNameShort} roles. Each user must still log in individually, but role assignment can be automated based on IdP group membership.
次のセクションでは、OpenID Connect およびSAML 2.0 認証プロトコルを使用して、2つのID プロバイダー（Microsoft Entra ID およびOkta）でSSO 構成を設定する方法について説明します。
## 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. **クライアントシークレット**プロパティを、Entra ID で生成した新しいクライアントシークレットの値に設定します。
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 Sync**）。
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} はクレームの詳細とともに成功メッセージを表示します。
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 管理コンソールにログインし、**アプリケーション > アプリ統合の作成**を選択します。
2. **新しいアプリ統合の作成**ダイアログボックスで、**サインイン方式**に**OIDC - OpenID Connect** を、**アプリケーションの種類**に**Web アプリケーション**を選択します。続いて、**次へ**をクリックします。
3. {siteName} にログインし、**設定 > SSO** を選択して**シングルサインオン（SSO）設定**ダイアログボックスを開きます。
4. Okta で、リダイレクトURI を、以下に示すように{siteNameShort} の**シングルサインオン（SSO）設定**ダイアログボックスで指定されている**コールバックURL** 値に設定します。
続いて、**次へ**をクリックしてアプリケーションを作成します。
5. Locate and copy the Issuer URL, as follows.
1. Click the **Sign-On** tab for your application in the Okta Admin Console.
2. Scroll to the **OpenID Connect ID Token** section.
3. Copy the URL from the **Issuer** field.
If you want to sign in through an authorization server, you must obtain the Issuer URL for that particular server. In the Okta Admin Console, click **Security** in the left navigation pane, and then select **API** to display the **Authorization Servers** list. Locate your authorization server and copy the URL from the **Issuer** field.
6. {siteNameShort} の**シングルサインオン（SSO）設定**ダイアログボックスで、次のプロパティを指定します：
1. **クライアントID** および**クライアントシークレット**プロパティを、Okta の**全般**タブにある対応する値に設定します。
2. Set **Discovery URL** to Issuer URL that you copied previously, and append the OpenID Connect Discovery endpoint (.well-known/openid-configuration).
**例：** https\://*MyOrganization*.okta.com/.well-known/openid-configuration
次に、**インポート**をクリックして、残りの設定を{siteNameShort} にインポートします。
7. {siteNameShort} で**保存およびテスト**をクリックして、SSO の設定を確認します。{siteNameShort} で新しいタブが開き、Microsoft アカウントでのサインインを求められます。テストに成功すると、{siteNameShort} はクレームの詳細とともに成功メッセージを表示します。
8. （オプション）{siteNameShort} ユーザーアカウントをフェデレーションId で更新します。
1. ステップ5 の**シングルサインオン（SSO）設定**ダイアログボックスから、フェデレーションId をコピーします。
2. **設定 > ユーザー**に移動します。次に、ユーザーアカウントを見つけて**編集**をクリックします。
3. ユーザーアカウントにフェデレーションId を追加します。次に、**保存**をクリックして変更を保存し、ダイアログボックスを終了します。
この時点で、OpenID Connect SSO の基本設定が完了し、ユーザーはOkta 経由で{siteNameShort} にログインできるようになりました。
### SAML 2.0 設定
SAML ベースのシングルサインオン（SSO）により、ユーザーは組織のID プロバイダーを通じてシームレスに認証できるため、ログイン時にジャストインタイムプロビジョニングが可能になります。次の手順では、SAML 2.0 プロトコルを使用してSSO 用にOkta を設定する方法について説明します。
1. Okta 管理コンソールにログインし、**アプリケーション > アプリ統合の作成**を選択します。この手順により、**新しいアプリ統合の作成**ダイアログボックスが開きます。
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} で新しいタブが開き、Microsoft アカウントでのサインインを求められます。テストに成功すると、{siteNameShort} はクレームの詳細とともに成功メッセージを表示します。
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 を介してそのユーザーを検索します。
* If a user does not exist, {siteNameShort} first uses group-to-role mappings to assign a role. If no mapping is found, {siteNameShort} then checks the default role. If no group-to-role mapping is found and no default role is configured, the user account is created without a role.
* If a user already exists, {siteNameShort} only uses group-to-role mappings to match the user's current role. If the mapping and current role do not match, {siteNameShort} updates the user's current role. There is no default-role matching during this process.
### ID プロバイダーにおける要件とマッピング
ID プロバイダーの要件は、SAML 2.0 またはOpenID Connect のどちらを使用するかによって異なります。このセクションでは、各認証方式のクレーム要件について説明します。
**OpenID Connect**
* デフォルトでは、サブコントロールはユーザーのロールにマッピングされ、クレームはフェデレーションId にマッピングされます。オプションとして、**admin** ユーザーは、{siteNameShort} で**Key Claim** プロパティを設定することにより、別のフィールド（例えば**oid**）を使用できます（**設定 > SSO > ユーザープロビジョニング**）。
* **email** クレームは、{siteNameShort} の**Email Address** にマッピングされます。
* **preferred\_username** クレームは、{siteNameShort} の**name** にマッピングされます。
**SAML 2.0**
* **NameID** と**Email** クレームは必須です。
* （オプション）**Name** クレームを追加できます。これは、{siteNameShort} の**Username** にマッピングされます。
* （オプション）**Role** クレームを追加できます。これは、ユーザーのロールを制御します。
### {siteNameShort} でのJIT 設定
{siteNameShort} でJIT プロビジョニングを有効化および設定するには：
1. 次の手順でJIT プロビジョニングを有効にします：
1. {siteNameShort} で**設定 > SSO** を選択します。
2. **編集**アイコン（
）をクリックして、**ユーザープロビジョニング**ダイアログボックスを開きます。
3. **JIT プロビジョニング**ラベルの下で**有効化**を選択します。
4. (Optional) If one is not set already, select a default role from the **SYNC ROLES** list.
5. **保存**をクリックして選択内容を保存し、ダイアログボックスを終了します。
ユーザーがログインすると、{siteNameShort} は次の順序でロールを調整します：
1. If the [group-to-role mapping](#group-to-role-mapping) finds a match, {siteNameShort} applies the mapped role or roles.
2. クレームにロールが含まれている場合、{siteNameShort} はそのロールを検索してユーザーアカウントを更新します。
3. If the **group** claim does not exist or there is no mapped {siteNameShort} role, the application uses the default role.
4. デフォルトロールが設定されていない場合、ユーザーアカウントにはロールがないため、**Admin** ユーザーが手動でユーザーのロールを更新する必要があります。
### グループからロールへのマッピング
In addition to assigning roles through a role claim or a default role, {siteNameShort} supports mapping of Identity Provider (IdP) groups to {siteNameShort} roles. This feature is useful when your IdP (for example, Microsoft Entra ID) issues group identifiers in the authentication token instead of role names.
{siteNameShort} でグループからロールへのマッピングを設定するには：
1. **設定 > SSO** を選択し、**編集**（
）をクリックして、**ユーザープロビジョニング**ダイアログボックスを開きます。
2. Scroll to the **GroupMapping** section and click **Add mappings** to open new mapping fields.
3. Enter the value that is returned by your IdP, according to the checks made by {siteNameShort}:
* **OpenID Connect:** {siteNameShort} checks only the value of the **groups** claim in the IdP response.
With Okta, the claim can contain group names; with Microsoft Entra ID, the claim contains group identifiers (GUIDs). Configure your mapping to match whatever your IdP issues.
* **SAML 2.0:** {siteNameShort} checks only the value from the **role** claim.
Then, select one or more {siteNameShort} roles to which you want to map the group.
4. When you finish adding mappings, click **Save** to exit the dialog box.
When a user logs in with JIT provisioning, {siteNameShort} assigns roles according to the rules described earlier in [Requirements and Mappings in Your Identity Provider](#requirements-and-mappings-in-your-identity-provider).
To delete a mapping, click the **Delete** icon (
).