> For the complete documentation index, see [llms.txt](https://docs.dispel.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dispel.com/documentation/documentation-ja/shisuru/identity-providers.md).

# ID プロバイダー（SSO）

既存の ID プロバイダーを使ってユーザーが Dispel にサインインできるようにします。Microsoft Entra ID、Okta、または PingIdentity を OAuth（OIDC）もしくは SAML 経由で接続して、シングルサインオンを実現します。

## 概要

アイデンティティ プロバイダー（IdP）を接続すると、ユーザーは他の場所で既に使用しているのと同じエンタープライズ資格情報で Dispel にサインインできます。これがシングル サインオン（SSO）です。別個の Dispel パスワードを管理する代わりに、IdP が認証を処理し、ユーザーが誰であるかを Dispel に通知します。

Dispel は 4 つのアイデンティティ プロバイダーをサポートしています。Active Directory は LDAP(S) 経由で接続し、Microsoft Entra ID、Okta、Ping Identity はそれぞれ OAuth（OIDC）または SAML のいずれかで接続します。

* [**Active Directory**](/documentation/documentation-ja/shisuru/identity-providers/active-directory.md) — Microsoft のオンプレミス ディレクトリ サービスです。
* [**Microsoft Entra ID**](/documentation/documentation-ja/shisuru/identity-providers/microsoft-entra-id.md) — Microsoft のクラウド アイデンティティ プラットフォームです（旧 Azure AD）。
* [**Okta**](/documentation/documentation-ja/shisuru/identity-providers/okta.md) — Okta のエンタープライズ アイデンティティ プラットフォームです。
* [**PingIdentity**](/documentation/documentation-ja/shisuru/identity-providers/ping-identity.md) — Ping のフェデレーテッド アイデンティティ プラットフォームです。

{% hint style="info" %}
**どこにあるか。** 組織管理者としてサインインし、 **設定 → 統合** （または専用の **設定 → 認証** ページ）を開きます。プロバイダーは **Identity & Authentication（IdP / SSO）** セクションに表示されます。 **接続** をクリックして開始します。
{% endhint %}

{% hint style="warning" %}
**組織ごとに 1 つのアイデンティティ プロバイダー。** 組織は、一度に 1 つのプロトコルを使用する単一の有効な IdP しか持てません。プロバイダーを切り替える、または既存のプロバイダーを OAuth と SAML の間で切り替えるには、まず現在のものを切断する必要があります。
{% endhint %}

## プロトコルの選択

使用するプロトコルは、接続するプロバイダーによって決まります。

* Active Directory は LDAP(S) のみで接続します。
* Microsoft Entra ID、Okta、Ping Identity はいずれも OAuth（OIDC）と SAML の両方をサポートしています。これらのいずれかを構成すると、2 つのプロトコルから選択できます。同時に有効にできるのは、プロバイダーごとに 1 つだけです。

これら 3 つのクラウド プロバイダーについては、IdP アプリケーションの設定方法に応じて OIDC と SAML を選択します。

| プロトコル            | 概要                                         | 次の場合に選択                                                  |
| ---------------- | ------------------------------------------ | -------------------------------------------------------- |
| **OAuth** （OIDC） | アクセス委任のためのオープン標準で、一般的にトークン ベースの認証に使用されます。  | IdP アプリが OIDC / OAuth アプリケーションとして設定されている場合。              |
| **SAML**         | 当事者間で認証および認可データを交換するための XML ベースのフレームワークです。 | IdP アプリが SAML アプリケーションとして設定されている場合、または組織の標準が SAML である場合。 |

> Active Directory は LDAP(S) を使用します。これは、TLS で保護されたディレクトリ サーバーに対してクエリと認証を行うためのプロトコルです。AD は LDAP(S) のみをサポートするため、プロトコルを選択する手順はありません。

## あなたが提供するものと、Dispel が提供するもの

SSO のセットアップは双方向のやり取りです。IdP に関する詳細を Dispel に提供し、SAML の場合は、Dispel のサービス プロバイダー詳細を IdP 側に貼り付けます。

#### OAuth（OIDC）

Dispel には以下を入力します。

| 項目                | 入力内容                                                                           |
| ----------------- | ------------------------------------------------------------------------------ |
| **クライアント URL**    | OAuth トークンが送信される URL。IdP の設定で確認できます。                                           |
| **クライアント ID**     | IdP 設定内にある、IdP の一意の識別子（多くの場合、URL または URN）。                                     |
| **クライアント シークレット** | IdP によって発行されたクライアント シークレット。                                                    |
| **組織識別子**         | 一意の識別子 *を* 選択します。ユーザーは Dispel のサインイン画面でこれを入力します。使用できるのは英字、数字、ダッシュ、アンダースコアのみです。 |

IdP 側で Dispel をアプリケーションとして登録し、その **リダイレクト URI** を Dispel のアドレスに続けて `/oauth/login-callback` （例： `https://app.dispel.com/oauth/login-callback`）。環境に応じた正確なアドレスが不明な場合は、Dispel の担当者に確認してください。

#### SAML

Dispel は SAML フォームの上部に 2 つの読み取り専用値を表示します。これらを IdP の SAML アプリケーションに貼り付けます。

| Dispel が提供するもの                     | IdP に貼り付ける内容                              |
| ---------------------------------- | ----------------------------------------- |
| **Service Provider（SP）Entity ID**  | SP の Entity ID / audience。                |
| **Assertion Consumer Service URL** | ACS URL / reply URL / single sign-on URL。 |

それぞれの横にある **ID をコピー** と **URL をコピー** ボタンを使用します。次に、Dispel には以下を入力します。

| 項目                              | 入力内容                                                                       |
| ------------------------------- | -------------------------------------------------------------------------- |
| **SSO URL**                     | SAML アサーションが送信される URL。IdP の設定で確認できます。                                      |
| **Identity Provider Entity ID** | IdP の一意の識別子（多くの場合、URL または URN）。                                            |
| **Base64 署名証明書**                | IdP が SAML アサーションに署名するために使用する証明書です。貼り付けるか、 **証明書をアップロード** を使用します（最大 1 MB）。 |
| **組織識別子**                       | 一意の識別子 *を* を選択します。ユーザーは Dispel のサインイン画面でこれを入力します。                          |

#### LDAP(S)

SSO フローとは異なり、LDAP はリダイレクト ベースのハンドシェイクではありません。Dispel はディレクトリに直接接続し、そこでユーザーを認証します。別のシステムに貼り戻すものはなく、設定はすべて Dispel 内で行います。以下の値は Active Directory 管理者から取得します。

Dispel には以下を入力します。

| 項目                        | 入力内容                                                                                                |
| ------------------------- | --------------------------------------------------------------------------------------------------- |
| **サインイン識別子**              | 一意の識別子 *を* を選択します。ユーザーは Dispel のサインイン画面でこれを入力します。                                                   |
| **Active Directory ドメイン** | AD の DNS ドメイン。例： `corp.example.com`.                                                                |
| **ドメイン コントローラー**          | Dispel が LDAPS（ポート 636）で接続するドメイン コントローラーのホスト名。例： `dc01.corp.example.com`.                           |
| **証明書の信頼 + CA 証明書**       | Dispel が TLS 接続を検証する方法と、推奨される、ドメイン コントローラーの証明書を発行した CA 証明書です。PKI または AD 管理者から入手します。PEM、CRT、または CER。 |
| **Bind DN または UPN**       | Dispel が認証に使用する読み取り専用のサービス アカウント。例： `svc-dispel@corp.example.com`.                                  |
| **Bind パスワード**            | サービス アカウントのパスワード。                                                                                   |
| **ユーザー検索ベース**             | ユーザーを検索するディレクトリの場所（OU）。例： `OU=Users,DC=corp,DC=example,DC=com`.                                     |
| **グループ検索ベース**             | グループを検索するディレクトリの場所（OU）。                                                                             |
| **ログイン属性**                | ユーザーがユーザー名として入力する属性。一般的には `sAMAccountName`.                                                         |

## プロバイダーの設定

IdP 側での具体的な手順はプロバイダーごとに異なります。詳細は各プロバイダーのページを参照してください。全体の流れは同じです。

1. 移動して **設定 → 統合** をクリックします **接続** プロバイダーのカード上で。
2. **認証プロトコルの選択** — OAuth または SAML。
3. *（SAML のみ）* Dispel の **SP Entity ID** と **ACS URL** を IdP の SAML アプリにコピーします。
4. IdP からの値で接続フィールドを埋め、 **組織識別子**.
5. 「 **設定を保存**.
6. *（SAML のみ）* 「 **接続をテスト**」をクリックします。Dispel はサインインのために IdP にリダイレクトし、受信したユーザー属性（メール、名、姓）を表示します。テストに失敗した場合は、詳細が IdP の SAML アプリと一致していること、テスト ユーザーが IdP に存在し、この組織に招待されていることを確認してください。

> Active Directory に接続しますか？AD は LDAP(S) を使用し、別のフローに従います。Dispel は SSO ハンドシェイクでリダイレクトするのではなく、ディレクトリに直接接続します。また、選択するプロトコルはありません。 [Active Directory セットアップ ガイド](/documentation/documentation-ja/shisuru/identity-providers/active-directory.md) で、全手順を確認してください。

{% hint style="info" %}
**シークレットはマスクされます。** 保存後、シークレット フィールド（クライアント シークレット、証明書）はマスクされます。後で編集する際は、マスクされたフィールドを変更せずにそのままにしておくと、保存済みの値が保持されます。
{% endhint %}

## ユーザーのサインイン方法

SSO が構成されると、ユーザーは Dispel パスワードではなく IdP でサインインします。

1. Dispel のサインイン画面で、ユーザーは **組織識別子**.
2. Dispel は認証のためにそれらを IdP にリダイレクトします。
3. 成功すると、ユーザーは Dispel に戻り、サインインされます。

Dispel はユーザーの **メールアドレス**, **名**と **姓** を IdP の応答から読み取ります。

{% hint style="info" %}
**ユーザーは先に招待されている必要があります。** SSO はユーザーの認証は行いますが、それだけでアクセス権を付与するわけではありません。SSO でサインインする前に、そのユーザーは Dispel で組織に招待されている必要があります。 [Dispel にユーザーを招待する](/documentation/documentation-ja/yztoakusesuwosuru/users/invite-a-user.md).
{% endhint %}

## グループ マッピング

IdP が送信するグループまたはクレームに基づいて、SSO ユーザーを Dispel のグループに自動的に割り当てることができます。グループ メンバーシップはサインインごとに再評価されるため、アクセス権は IdP と常に同期されます。 [OIDC グループ マッピング](/documentation/documentation-ja/shisuru-2/integrations/oidc-group-mapping.md).

## SSO と多要素認証

SSO を使用している場合、IdP が認証を担当します。そこに設定した MFA も含まれます。その結果、SSO 経由でサインインするユーザーには、Dispel のメール ワンタイムコードは適用されません。 [ポリシー ビルダー](/documentation/documentation-ja/shisuru/policy-builder.md).

## プロバイダーの切り替えまたは切断

プロバイダーを変更する場合、またはプロバイダーを OAuth と SAML の間で切り替える場合は、 **切断** を最初に実行してから、新しいものを接続します。

{% hint style="warning" %}
**切断するとパスワードのリセットが強制されます。** SSO 統合を削除すると、影響を受けるユーザーは IdP 経由でサインインできなくなります。再度サインインするには Dispel パスワードをリセットする必要があり、再接続するにはすべてのフィールドを再入力する必要があります。
{% endhint %}

## よくある質問

<details>

<summary>一度に複数のアイデンティティ プロバイダーを使用できますか？</summary>

いいえ。組織が一度にアクティブにできる IdP は 1 つだけです。すでに 1 つのプロバイダーに接続している場合、切断するまで他のプロバイダーは利用できません。現在別のプロバイダーに接続しており、まずそれを切断する必要がある旨の注意が表示されます。

</details>

<details>

<summary>同じプロバイダーで OAuth と SAML の両方を使用できますか？</summary>

いいえ。アイデンティティ プロバイダーごとに、一度にサポートされる認証プロトコルは 1 つだけです。プロトコルを切り替えるには、切断してから別のプロトコルで再接続してください。

</details>

<details>

<summary>Organization Identifier とは何ですか？</summary>

これは、あなたが選ぶ短くて一意のラベルです（英字、数字、ダッシュ、アンダースコア）。ユーザーは Dispel のサインイン画面でこれを入力し、Dispel はどの IdP に送るべきかを判断します。

</details>

<details>

<summary>ユーザーは最初の SSO サインイン時に自動的にアカウントが作成されますか？</summary>

そのユーザーがすでに組織に招待されている場合のみです。SSO はユーザーが誰かを証明しますが、アクセスを得るには Dispel での招待が必要です。

</details>

<details>

<summary>SSO を構成できるのは誰ですか？</summary>

組織管理者です。アイデンティティ プロバイダーの構成または切断には、組織編集権限が必要です。

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.dispel.com/documentation/documentation-ja/shisuru/identity-providers.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.