> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.com/llms.txt
> Use this file to discover all available pages before exploring further.
# プロビジョニング（B2B）
> B2B IAMの実装について、ユーザーのプロビジョニングの機能性と考慮するべき事項について説明します。
ユーザーがどのようにしてサインアップするかを決めることは、早期に検討するべき重要事項です。そこでの決定内容が、今後必要となる多くの決定事項に影響を与えます。ユーザーがシステムに追加される方法には一般的なパターンがあり、ワークフローの設計を考える際に注意するべき事柄があります。
### ベストプラクティス
Auth0はさまざまなワークフローをサポートしていますが、サインアップにはAuth0[ユニバーサルログイン](/docs/ja-jp/login/universal-login)を使用したWebベースのワークフローが、最適な機能性と最高のセキュリティを提供するという点で、業界でもAuth0にとってもベストプラクティスとみなされています。
Auth0は、いくつかの異なる[IDプロバイダー](/docs/ja-jp/authenticate/identity-providers)を通したサインアップに対応しています。サインアップ中には、Auth0が[ユーザープロファイル]()をプロビジョニングするため、ユーザーのアカウント情報が含まれます。機能性とワークフローを検討する際には、以下のように、考慮するべき事柄がいくつかあります。
* ユーザーが貴社のドメインに追加されるのか、それとも、ユーザーの所属組織のドメインに留まるのか
* ユーザーが独自のドメインに留まる場合、単一の組織の属するのか、それとも、複数の組織に属するのか
* システム内で組織自体をどのようにしてプロビジョニングするのか
* Auth0をIDストアとして使用するべきなのか
* 独自の（レガシー）IDストアをAuth0で使用できるのか
* 使用しているIDストアからAuth0に、どのようにしてユーザーIDを移行するのか
* ユーザーは自分の組織のIDプロバイダーを使ってサインアップできるのか
* ユーザーは招待されるのか、それとも、自分で登録するのか
他のビジネスにサービスを提供するにあたって、最初に特定するべきことの1つに、ユーザーが属しているドメインがあります。それが何であるかを基に、ユーザーをプロビジョニングする方法が2通りに分かれます。詳細については、「[組織のユーザーをプロビジョニングする](#provisioning-organization-users)」を参照してください。組織がシステムでどのように準備されるのかが決まったら、組織自体をどのようにしてプロビジョニングするのかを検討します。詳細については、「[組織をプロビジョニングする](#provisioning-organizations)」を参照してください。
Auth0はそのままで便利に使えるIDストレージを提供しているため、ユーザーの資格情報を安全に保管することができます。詳細については、「[セルフサインアップ](#self-sign-up)」を参照してください。すでにレガシーIDストアがあり、管理の負担を軽くしたい場合には、[ユーザーの移行](#user-migration)機能に利用できるいくつかのオプションがあります。
まだ移行したくない、または、移行できないアプリケーションがあるなどの理由で、レガシーIDストアを管理しなければならない場合には、[IDストアプロキシ](#identity-store-proxy)機能を使うことができます。顧客が個人IDの持ち込み（BYOI）を行えるようにするのも、方法として効果的です。最初から持ち込みを行う利用者はあまり見かけませんが、[ソーシャルサインアップ](#social-sign-up)機能を使うと提供することができます。
## 組織をプロビジョニングする
### Auth0ビデオで始める
[「準備：ユーザーストア」](/docs/ja-jp/videos/get-started/02-provision-user-stores)と[「準備：ユーザーのインポート」](/docs/ja-jp/videos/get-started/03-provision-import-users)の2つのビデオを観て、Auth0テナント内でユーザープロファイルがプロビジョニングされる方法と、Auth0がAuth0ユーザーストアに既存ユーザーを移動させる方法について学びましょう。
組織のプロビジョニングに必要なことは、システム内で組織一般がどのように存在しているかによります。それには、これらの組織のユーザーがどのようにアプリケーションとやり取りするかを考慮するための時間が必要になるかもしれません。「[複数組織のアーキテクチャ](/docs/ja-jp/get-started/architecture-scenarios/multiple-organization-architecture)」を参照して、IAMシステムに組織をどのように構成するか決定してください。
* 独自のアプリケーションの構成とデータベースの両方または片方に組織の追加が必要になります。
* 使用しているAuth0の構成を変更する必要があります。これには、以下の一部またはすべてが含まれます。
* 例外的な場合：組織に一意のテナントを作成する
* Auth0テナント内に新しい組織を作成する
* その組織のデータベース接続を追加する（組織ごとにユーザーを分離する場合）
* 既存の共有されたデータベース接続を組織で有効化する（ユーザーを共有している場合）
* この組織にエンタープライズ接続を追加し、組織に対して有効化する
* これには、レガシー組織でない場合に、組織について、既存の構成を更新するか、Auth0テナントに構成を追加する作業が含まれます。
* 組織の管理者をプロビジョニングする
* 間違いを防ぐために、[組織管理者ポータル](#organization-admin-portal)を作成して、新しい組織をプロビジョニングしやすくすることをお勧めします。
* 組織にセルフサインアップポータルを作成することもお勧めします。ユーザーが自分で組織を作成できるようになります。これは、[組織管理者ポータル](#organization-admin-portal)の一部にすることもできます。
### 組織管理者ポータル
組織のプロビジョニングでは、以下を考慮する必要があります。
組織管理者ポータルでは、管理者が組織の作成、編集、削除を行えます。会社の従業員または顧客の管理者が、このような管理者になることができます。独自のシステムとAuth0テナントの両方で、複数の作業を実行する必要があります。このポータルは、システム内のデータストアと構成にアクセスできるよう、独自のシステム内に必要となる可能性があります。ただし、Auth0は[Auth0 Management API](/docs/ja-jp/api/management/v2)を提供しているため、独自のシステム内で変更を行うと同時に、変更内容をAuth0テナントに反映することができます。
* **Auth0テナントにライブで更新** ：新しい組織をリアルタイムに作成したい場合には、Auth0 Management APIを使って、Auth0テナントを直接変更することをお勧めします。変更内容がリアルタイムで反映されるため、新しい組織の追加も即座に反映されます。特に、組織にセルフサインアップをプロビジョニングしている場合には、この方法をお勧めします。
新しい組織を作成するには、主に2つの方法があります。どちらを選択するかは、新しい組織がデプロイされるまでに、どれだけの時間的な余裕があるかに依存します。
* **リポジトリを変更してデプロイし直す** ：[CI/CDパイプライン](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/deployment)の一部としてDeploy CLI（またはカスタムCLI）を活用している場合には、変更内容をリポジトリに直接プッシュしてから、新しいデプロイを始める方が好ましいかもしれません。多少時間がかかりますが、バージョン履歴や、以前のバージョンをデプロイし直して変更を取り消せるなどの利点があります。組織が必要とするアイテムだけを含む別のリポジトリを持つことで、他の共通コンポーネントをデプロイし直す必要や、エラーが発生するリスクもなくなります。
## ユーザーの移行
ライブアップデートには、いくつか考慮すべき点があり、一連の操作を順番に行うことで問題の発生を防がなければなりません。たとえば、接続でクライアントを有効にすること、アプリケーションにコールバックURLを追加すること、などです。Management APIで行う操作のうち、リスト全体を取得してそれに新しい値を追加し、リストを再発行するものは、必ず2つの操作を順番に実行しなければなりません。2つの操作が同時に行われると、いずれかの値が上書きされてしまうためです。
[ユーザープロファイル](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/profile-management)をホストするだけでなく、Auth0はレガシーIDストアの[プロキシ](#identity-store-proxy)機能を備え、安全なAuth0ホストのIDストアを提供しています。これらの機能はどちらも、Auth0の[データベース接続](/docs/ja-jp/authenticate/database-connections)を使うことでサポートされます。レガシーIDストアの代わりにAuth0を使うことに決めた場合は、一括移行で一気に[ユーザーを移行](/docs/ja-jp/manage-users/user-migration)するか、自動移行で段階的に移行することができます。
### ベストプラクティス
当社の多くの顧客の方は、2段階でのユーザー移行を選びます。まず自動移行を行ってできるだけ多くのアクティブユーザーを移行し、次に自動移行をオフにして一括移行で残りのユーザーを移行する、というアプローチです。詳細については、[「ユーザー移行シナリオ」](/docs/ja-jp/users/import-and-export-users/user-migration-scenarios)をご覧ください。
自動移行は、ユーザーを個別に移行したい場合にお勧めします。また、ほぼすべての状況で、ユーザーは既存のパスワードを維持することができます。一括移行では、[Management API](/docs/ja-jp/api/management/v2#!/Jobs/post_users_imports)の使用をお勧めします。[User Import/Export（ユーザーインポート/エクスポート）拡張機能](/docs/ja-jp/manage-users/user-migration/user-import-export-extension)に比べて、Management APIには高い柔軟性と制御が備わっているため、シンプルな状況のほとんどで有効です。
対応アルゴリズムの1つを使ってパスワードがハッシュ化され、レガシーIDストアに保管されていない限り、ユーザーの一括移行では通常、**移行の完了後にパスワードのリセット** が必要になります。その場合、使用しているアルゴリズムとソルトラウンド数によっては、一括移行で**ユーザーのパスワードを維持** することができます。詳細については、「[一括インポートのデータベーススキームの例](/docs/ja-jp/manage-users/user-migration/bulk-user-import-database-schema-and-examples)」を参照してください。
ハッシュ化したパスワードのインポートは、argon2、bcrypt、hmac、ldap、md4、md5、sha1、sha256、sha512、pbkdf2、scryptのいずれか1つのアルゴリズムに準拠する実装を使ったソースIDストアに依存しています。
### IDストアプロキシ
### ベストプラクティス
Management APIへの呼び出しは、[「Auth0のレート制限ポリシー」](/docs/ja-jp/support/policies/rate-limit-policy)の対象となります。Auth0は通常、APIを直接呼び出す代わりに、開発環境に適した[Auth0 SDK](/docs/ja-jp/libraries)の使用を推奨していることにご注意ください。
## 組織のユーザーをプロビジョニングする
Auth0のデータベース接続タイプは、既存の（レガシー）IDストアをプロキシするように構成することもできます。たとえば、ビジネスに不可欠な1つ以上のアプリケーションがあり、Auth0には移行できないけれど、それらのIDにはアクセスする必要があるケースなど、独自のレガシーストアにユーザーIDを保持しなければならない場合には、Auth0と手軽に統合することができます。詳細については、「[独自のデータベースを使用してユーザーを認証する](/docs/ja-jp/authenticate/database-connections/custom-db)」を参照してください。
* **組織で分離** ：それぞれのユーザーは1つの組織だけに属します。ユーザーが複数の組織に属しても意味を持たないためです。仮に複数の組織に属する必要があったとしても、それぞれの組織に個別のIDを持った方が理にかなっています。たとえば、小売店のある従業員が2つの店舗でパートタイムとして働いている場合、両方の店舗で同じSaaSアプリケーションが使われていても、この従業員には両店舗で異なるログインが提供され、使用されます。詳細については、「[組織に分離されたユーザーをプロビジョニングする](#provisioning-users-isolated-to-the-organization)」を参照してください。
* **組織間で共有** ：この場合、ユーザーは、貴社で資格情報を作成するか、ユーザー自身の組織が作成した資格情報を使って貴社アプリケーションの他組織インスタンスにアクセスすることができます。簡単に言うと、1人のユーザーが1つ以上の組織のアプリケーションインスタンスにアクセスすることになります。ユーザーは、両方のアプリケーションインスタンスに同じ資格情報を使ってアクセスすることができます。たとえば、複数のクリニックと契約している医師が、それぞれのクリニックで同じ資格情報を使ってサインインできるようにしなければならない場合などです。詳細については、「[組織間で共有のユーザーをプロビジョニングする](#provisioning-users-shared-between-organizations)」を参照してください。
### 組織に分離されたユーザーをプロビジョニングする
組織は、ビジネスの顧客やパートナーの1つと直接マッピングされなければなりません。取引のあるビジネスやパートナーのそれぞれには、ログインするユーザーがいます。それらのエンドユーザーは「組織のユーザー」と呼ばれます。組織のユーザーを保管するには、以下の2通りの方法があります。
ユーザーを組織で分離すると、組織間を境界ではっきりと分けることができます。ユーザーが複数の組織にアクセスする必要が一切ない場合（または、必要があれば複数のアカウントを作成させたい場合）には、この方法が適しています。
* **Auth0テナントがIdP** ：この組織専用のメインのテナントにあるデータベース接続です。
* **組織が独自のIdPを使用** ：組織にエンタープライズ接続をセットアップします。
* **組織が複数のIdPを使用** ：1つ以上のエンタープライズ接続やソーシャル接続を有効化します。データベース接続が1つ含まれていても構いません。ユーザーが組織を選択してログインする際には、その組織に有効化されているすべての接続から選ぶことができます。
そのようなユーザーはIdPレベルでプロビジョニングする必要があります。そのため、組織のそれぞれが独自のIdPを使うことになります。このIdPには以下の3種類があります。
[ユーザー招待ワークフロー](/docs/ja-jp/manage-users/organizations/configure-organizations/invite-members)は実装しやすいため、手始めにAuth0をIdPとして使用することをお勧めします。他の招待フローと比較して唯一異なるのは、ユーザーを作成している人が前もって組織を選択するか、システムが組織を招待者ユーザーのものと強制的に合致させる（組織の管理者がその管理組織だけに属するような場合）点です。
### 組織間で共有のユーザーをプロビジョニングする
### ベストプラクティス
[「Organization機能」](/docs/ja-jp/organizations)を活用できれば、ログインシステムを大幅に簡易化でき、今後の維持と拡張がしやすくなります。詳細は、[「複数のOrganizationアーキテクチャ」](/docs/ja-jp/architecture-scenarios/multiple-organization-architecture)をご覧ください。
### デプロビジョニングの制限
組織間でユーザーを共有するには、アクセスを認可する方法が必要になります。認証時にはユーザーの所属が分からないため、一般的に推奨されるのは、ユーザーを1つのドメインに保管しておいてから、どの組織にアクセス可能にするかを考えて、ユーザーを[組織のメンバー](/docs/ja-jp/manage-users/organizations/configure-organizations/assign-members)として追加することです。このため、プロビジョニングは通常、1つのデータベース接続にユーザー招待ワークフローを使うことから始まり、Management APIを使ってユーザーが組織に追加されます。その後、ユーザーが組織間で切り替えられるように、Management APIを使って[ユーザーが属する組織](/docs/ja-jp/manage-users/organizations/configure-organizations/retrieve-user-membership)を取得することができます。
## ユーザーの招待
Auth0とのアクティブなSSOセッションがある場合、`prompt=login`で強制されない限り、Auth0はアップストリームのIdPとはやり取りしません。顧客の組織の1つがユーザーのログアウトを管理できない場合には、ユーザーがデコミッションされた後でも、アクセス可能なまま残る可能性があります。IdPによっては、Auth0がAPIのトークンを取得すると、ユーザーにまだアクセス権があるかをポーリングする[ルール](/docs/ja-jp/customize/rules)を使って、IdPからのユーザー情報を要求することができます。これが行えない場合は、API呼び出しやUIを使って、ブロックやユーザーのデコミッションをシステムでトリガーする方法を顧客の組織に提供する必要があります。
ほとんどのB2Bのシナリオでは、特定の人だけがアプリケーションへのアクセスを許されます。そのため、通常は、ユーザーがサインアップして管理者がそれを承認するよりも、管理者がユーザーアカウントをプロビジョニングする方が簡単になります。プロビジョニングは通常、ユーザーが中央管理システムに追加されると自動的に行われます。
* 貴社の管理者。各組織にユーザーを作成する可能性があります。
* 各組織の管理者。ユーザーの作成を担当している可能性があります。
* ユーザーの作成を行う別のシステム。Auth0でもユーザーを作成している可能性があります。オーディエンスにかかわらず、手段は同様です。アプリケーションに適した認可モデルを使用することだけが問題となります。
以下の異なる3つのペルソナが[ユーザーを招待](https://auth0.com/docs/design/creating-invite-only-applications)する可能性があります。
ユーザーを招待するには、[Organizations機能](/docs/ja-jp/manage-users/organizations/configure-organizations/invite-members)の使用をお勧めします。ユーザー招待の実装にOrganization機能を使用して**おらず** 、独自の機能を構築している場合は、`user.email_verified`パラメーターに`false`を設定して各ユーザーを作成し、ランダムで一時的なパスワードを持たせるようにすることが重要です。生成されたパスワードを知っているのはAuth0だけにします。外部システムで保管したり、ユーザーに渡したりしては**いけません** 。それから、[Management API](https://auth0.com/docs/api/management/v2#!/Tickets/post_password_change)を使って、パスワードのリセットリンクをメールでユーザーに送信します。メールテンプレートはAuth0で編集して、招待でのサインアップワークフローに沿ったものにカスタマイズできます。これにより、ユーザーのメールアドレスが、作成されたユーザーのものだと保証され、パスワードを知っているのはユーザー自身だけになります。
## エンタープライズサインアップ
OIDCの主な原則の1つは、ユーザー本人以外にパスワードを知っている人はいない、ということです。招待フローを実行する場合は、バックエンドシステムでパスワードをランダムに生成してから破棄し、ユーザーがパスワードをリセットして初めてログインが可能になるようにします。一時パスワードを作成してユーザーに渡し、それを初回のログイン時に使用させるようなことはしないでください。
エンタープライズサインアップは、[エンタープライズログイン](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/authentication)を使ったサインアップと同じです。初回のエンタープライズログインでユーザー[プロファイル](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/profile-management)が自動的に作成されるため、本質的な違いはありません。
### ベストプラクティス
顧客が独自のIdPを使用できるようにすることの利点の1つは、顧客が独自のIdPセットアップでユーザーを管理し、ロールとアクセスを割り当てることができるため、顧客のために管理機能を構築する必要がないということです。顧客のマッピングを解決することで、これははるかに簡単になります。 :::
マッピングだけでは不十分で、システムにメタデータを追加しなければならない場合は、ユーザーが初めてシステムにログインするまでそのユーザーがAuth0内に作成されないことに注意してください。そのため、ルール拡張機能を使って他の場所から初期情報を取得するか、ユーザーにログインを強制しない限り、メタデータを追加することはできません。
## プロジェクト計画ガイド
当社では、PDF形式の計画ガイダンスを提供しています。ダウンロードして、推奨される戦略の詳細を参照してください。
[B2B IAM Project Planning Guide](http:///assets.ctfassets.net/cdy7uua7fh8z/63F0WOPJdVzsPMxV1Xvp8x/7a329487c5e890d8e820f6a48983b46a/B2B_Project_Planning.pdf)