プロビジョニング（B2B）

ユーザーがどのようにしてサインアップするかを決めることは、早期に検討するべき重要事項です。そこでの決定内容が、今後必要となる多くの決定事項に影響を与えます。ユーザーがシステムに追加される方法には一般的なパターンがあり、ワークフローの設計を考える際に注意するべき事柄があります。

Auth0は、いくつかの異なるIDプロバイダーを通したサインアップに対応しています。サインアップ中には、Auth0がユーザープロファイルをプロビジョニングするため、ユーザーのアカウント情報が含まれます。機能性とワークフローを検討する際には、以下のように、考慮するべき事柄がいくつかあります。

• ユーザーが貴社のドメインに追加されるのか、それとも、ユーザーの所属組織のドメインに留まるのか

• ユーザーが独自のドメインに留まる場合、単一の組織の属するのか、それとも、複数の組織に属するのか

• システム内で組織自体をどのようにしてプロビジョニングするのか

• Auth0をIDストアとして使用するべきなのか

• 独自の（レガシー）IDストアをAuth0で使用できるのか

• 使用しているIDストアからAuth0に、どのようにしてユーザーIDを移行するのか

• ユーザーは自分の組織のIDプロバイダーを使ってサインアップできるのか

• ユーザーは招待されるのか、それとも、自分で登録するのか

他のビジネスにサービスを提供するにあたって、最初に特定するべきことの1つに、ユーザーが属しているドメインがあります。それが何であるかを基に、ユーザーをプロビジョニングする方法が2通りに分かれます。詳細については、「組織のユーザーをプロビジョニングする」を参照してください。組織がシステムでどのように準備されるのかが決まったら、組織自体をどのようにしてプロビジョニングするのかを検討します。詳細については、「組織をプロビジョニングする」を参照してください。

Auth0はそのままで便利に使えるIDストレージを提供しているため、ユーザーの資格情報を安全に保管することができます。詳細については、「セルフサインアップ」を参照してください。すでにレガシーIDストアがあり、管理の負担を軽くしたい場合には、ユーザーの移行機能に利用できるいくつかのオプションがあります。

まだ移行したくない、または、移行できないアプリケーションがあるなどの理由で、レガシーIDストアを管理しなければならない場合には、IDストアプロキシ機能を使うことができます。顧客が個人IDの持ち込み（BYOI）を行えるようにするのも、方法として効果的です。最初から持ち込みを行う利用者はあまり見かけませんが、ソーシャルサインアップ機能を使うと提供することができます。

組織のプロビジョニングに必要なことは、システム内で組織一般がどのように存在しているかによります。それには、これらの組織のユーザーがどのようにアプリケーションとやり取りするかを考慮するための時間が必要になるかもしれません。「複数組織のアーキテクチャ」を参照して、IAMシステムに組織をどのように構成するか決定してください。

• 独自のアプリケーションの構成とデータベースの両方または片方に組織の追加が必要になります。

• 使用しているAuth0の構成を変更する必要があります。これには、以下の一部またはすべてが含まれます。

  • 例外的な場合：組織に一意のテナントを作成する

  • Auth0テナント内に新しい組織を作成する

  • その組織のデータベース接続を追加する（組織ごとにユーザーを分離する場合）

  • 既存の共有されたデータベース接続を組織で有効化する（ユーザーを共有している場合）

  • この組織にエンタープライズ接続を追加し、組織に対して有効化する

    • これには、レガシー組織でない場合に、組織について、既存の構成を更新するか、Auth0テナントに構成を追加する作業が含まれます。

  • 組織の管理者をプロビジョニングする

• 間違いを防ぐために、組織管理者ポータルを作成して、新しい組織をプロビジョニングしやすくすることをお勧めします。

• 組織にセルフサインアップポータルを作成することもお勧めします。ユーザーが自分で組織を作成できるようになります。これは、組織管理者ポータルの一部にすることもできます。

組織のプロビジョニングでは、以下を考慮する必要があります。

組織管理者ポータルでは、管理者が組織の作成、編集、削除を行えます。会社の従業員または顧客の管理者が、このような管理者になることができます。独自のシステムとAuth0テナントの両方で、複数の作業を実行する必要があります。このポータルは、システム内のデータストアと構成にアクセスできるよう、独自のシステム内に必要となる可能性があります。ただし、Auth0はAuth0 Management APIを提供しているため、独自のシステム内で変更を行うと同時に、変更内容をAuth0テナントに反映することができます。

• Auth0テナントにライブで更新：新しい組織をリアルタイムに作成したい場合には、Auth0 Management APIを使って、Auth0テナントを直接変更することをお勧めします。変更内容がリアルタイムで反映されるため、新しい組織の追加も即座に反映されます。特に、組織にセルフサインアップをプロビジョニングしている場合には、この方法をお勧めします。

新しい組織を作成するには、主に2つの方法があります。どちらを選択するかは、新しい組織がデプロイされるまでに、どれだけの時間的な余裕があるかに依存します。

• リポジトリを変更してデプロイし直す：CI/CDパイプラインの一部としてDeploy CLI（またはカスタムCLI）を活用している場合には、変更内容をリポジトリに直接プッシュしてから、新しいデプロイを始める方が好ましいかもしれません。多少時間がかかりますが、バージョン履歴や、以前のバージョンをデプロイし直して変更を取り消せるなどの利点があります。組織が必要とするアイテムだけを含む別のリポジトリを持つことで、他の共通コンポーネントをデプロイし直す必要や、エラーが発生するリスクもなくなります。

ユーザープロファイルをホストするだけでなく、Auth0はレガシーIDストアのプロキシ機能を備え、安全なAuth0ホストのIDストアを提供しています。これらの機能はどちらも、Auth0のデータベース接続を使うことでサポートされます。レガシーIDストアの代わりにAuth0を使うことに決めた場合は、一括移行で一気にユーザーを移行するか、自動移行で段階的に移行することができます。

自動移行は、ユーザーを個別に移行したい場合にお勧めします。また、ほぼすべての状況で、ユーザーは既存のパスワードを維持することができます。一括移行では、Management APIの使用をお勧めします。User Import/Export（ユーザーインポート/エクスポート）拡張機能に比べて、Management APIには高い柔軟性と制御が備わっているため、シンプルな状況のほとんどで有効です。

対応アルゴリズムの1つを使ってパスワードがハッシュ化され、レガシーIDストアに保管されていない限り、ユーザーの一括移行では通常、移行の完了後にパスワードのリセットが必要になります。その場合、使用しているアルゴリズムとソルトラウンド数によっては、一括移行でユーザーのパスワードを維持することができます。詳細については、「一括インポートのデータベーススキームの例」を参照してください。

Auth0のデータベース接続タイプは、既存の（レガシー）IDストアをプロキシするように構成することもできます。たとえば、ビジネスに不可欠な1つ以上のアプリケーションがあり、Auth0には移行できないけれど、それらのIDにはアクセスする必要があるケースなど、独自のレガシーストアにユーザーIDを保持しなければならない場合には、Auth0と手軽に統合することができます。詳細については、「独自のデータベースを使用してユーザーを認証する」を参照してください。

• 組織で分離：それぞれのユーザーは1つの組織だけに属します。ユーザーが複数の組織に属しても意味を持たないためです。仮に複数の組織に属する必要があったとしても、それぞれの組織に個別のIDを持った方が理にかなっています。たとえば、小売店のある従業員が2つの店舗でパートタイムとして働いている場合、両方の店舗で同じSaaSアプリケーションが使われていても、この従業員には両店舗で異なるログインが提供され、使用されます。詳細については、「組織に分離されたユーザーをプロビジョニングする」を参照してください。

• 組織間で共有：この場合、ユーザーは、貴社で資格情報を作成するか、ユーザー自身の組織が作成した資格情報を使って貴社アプリケーションの他組織インスタンスにアクセスすることができます。簡単に言うと、1人のユーザーが1つ以上の組織のアプリケーションインスタンスにアクセスすることになります。ユーザーは、両方のアプリケーションインスタンスに同じ資格情報を使ってアクセスすることができます。たとえば、複数のクリニックと契約している医師が、それぞれのクリニックで同じ資格情報を使ってサインインできるようにしなければならない場合などです。詳細については、「組織間で共有のユーザーをプロビジョニングする」を参照してください。

組織は、ビジネスの顧客やパートナーの1つと直接マッピングされなければなりません。取引のあるビジネスやパートナーのそれぞれには、ログインするユーザーがいます。それらのエンドユーザーは「組織のユーザー」と呼ばれます。組織のユーザーを保管するには、以下の2通りの方法があります。

ユーザーを組織で分離すると、組織間を境界ではっきりと分けることができます。ユーザーが複数の組織にアクセスする必要が一切ない場合（または、必要があれば複数のアカウントを作成させたい場合）には、この方法が適しています。

• Auth0テナントがIdP：この組織専用のメインのテナントにあるデータベース接続です。

• 組織が独自のIdPを使用：組織にエンタープライズ接続をセットアップします。

• 組織が複数のIdPを使用：1つ以上のエンタープライズ接続やソーシャル接続を有効化します。データベース接続が1つ含まれていても構いません。ユーザーが組織を選択してログインする際には、その組織に有効化されているすべての接続から選ぶことができます。

そのようなユーザーはIdPレベルでプロビジョニングする必要があります。そのため、組織のそれぞれが独自のIdPを使うことになります。このIdPには以下の3種類があります。

ユーザー招待ワークフローは実装しやすいため、手始めにAuth0をIdPとして使用することをお勧めします。他の招待フローと比較して唯一異なるのは、ユーザーを作成している人が前もって組織を選択するか、システムが組織を招待者ユーザーのものと強制的に合致させる（組織の管理者がその管理組織だけに属するような場合）点です。

組織間でユーザーを共有するには、アクセスを認可する方法が必要になります。認証時にはユーザーの所属が分からないため、一般的に推奨されるのは、ユーザーを1つのドメインに保管しておいてから、どの組織にアクセス可能にするかを考えて、ユーザーを組織のメンバーとして追加することです。このため、プロビジョニングは通常、1つのデータベース接続にユーザー招待ワークフローを使うことから始まり、Management APIを使ってユーザーが組織に追加されます。その後、ユーザーが組織間で切り替えられるように、Management APIを使ってユーザーが属する組織を取得することができます。

Auth0とのアクティブなSSOセッションがある場合、prompt=loginで強制されない限り、Auth0はアップストリームのIdPとはやり取りしません。顧客の組織の1つがユーザーのログアウトを管理できない場合には、ユーザーがデコミッションされた後でも、アクセス可能なまま残る可能性があります。IdPによっては、Auth0がAPIのトークンを取得すると、ユーザーにまだアクセス権があるかをポーリングするルールを使って、IdPからのユーザー情報を要求することができます。これが行えない場合は、API呼び出しやUIを使って、ブロックやユーザーのデコミッションをシステムでトリガーする方法を顧客の組織に提供する必要があります。

ほとんどのB2Bのシナリオでは、特定の人だけがアプリケーションへのアクセスを許されます。そのため、通常は、ユーザーがサインアップして管理者がそれを承認するよりも、管理者がユーザーアカウントをプロビジョニングする方が簡単になります。プロビジョニングは通常、ユーザーが中央管理システムに追加されると自動的に行われます。

• 貴社の管理者。各組織にユーザーを作成する可能性があります。

• 各組織の管理者。ユーザーの作成を担当している可能性があります。

• ユーザーの作成を行う別のシステム。Auth0でもユーザーを作成している可能性があります。オーディエンスにかかわらず、手段は同様です。アプリケーションに適した認可モデルを使用することだけが問題となります。

以下の異なる3つのペルソナがユーザーを招待する可能性があります。

ユーザーを招待するには、Organizations機能の使用をお勧めします。ユーザー招待の実装にOrganization機能を使用しておらず、独自の機能を構築している場合は、user.email_verifiedパラメーターにfalseを設定して各ユーザーを作成し、ランダムで一時的なパスワードを持たせるようにすることが重要です。生成されたパスワードを知っているのはAuth0だけにします。外部システムで保管したり、ユーザーに渡したりしてはいけません。それから、Management APIを使って、パスワードのリセットリンクをメールでユーザーに送信します。メールテンプレートはAuth0で編集して、招待でのサインアップワークフローに沿ったものにカスタマイズできます。これにより、ユーザーのメールアドレスが、作成されたユーザーのものだと保証され、パスワードを知っているのはユーザー自身だけになります。

エンタープライズサインアップは、エンタープライズログインを使ったサインアップと同じです。初回のエンタープライズログインでユーザープロファイルが自動的に作成されるため、本質的な違いはありません。

当社では、PDF形式の計画ガイダンスを提供しています。ダウンロードして、推奨される戦略の詳細を参照してください。