Skip to main content
組織ベースのシナリオにおけるプロファイル管理は、基本的には他のアーキテクチャシナリオの場合と同じです。アーキテクチャシナリオでは、ここで説明する内容とあわせて確認することを推奨する、汎用的な B2B プロファイル管理 のガイダンスも提供しています。
ユーザーに関連付けられたロールを管理するには、まず Auth0 にユーザーアカウントが存在している必要があります。これは、メンバーシップに関連付けられた Auth0 Organizations の Role 機能 を使用している場合でも同様です。ただし、user invitation ワークフローでプロビジョニングされたユーザーアカウントには、招待プロセスの一環としてロールを自動的に割り当てることができます。詳しくは、organization のメンバーを招待する を参照してください。別の仕組みでユーザーを事前登録する場合は、ロール情報を Auth0 の外部に保存し、最初の認証時に拡張 (たとえば Rule の一部として) を使ってその情報にアクセスまたはコピーする必要があります。
アプリケーションには、特定のユーザー属性のセット (たとえば、ユーザー設定や、顧客により適したサービスを提供するために使用する識別情報) が関連付けられており、それらについてユーザー向けの何らかのセルフサービス管理機能を提供している場合があります。または、通常は (IdP) によって管理される属性に対して、セルフサービスのプロファイル管理を提供することもできます。
Best Practice組織関連のシナリオでは、メールアドレスは常に確認済みであるべきです。そのため、ユーザーのメールアドレスを他の方法で確認できない場合に備えて、セルフサービスのメールアドレス確認機能を提供する必要があります。詳しくは、Email Verification を参照してください。

​
データベース接続

Auth0 では、Auth0 の を使用して、セルフサービスのプロファイル管理サポートを実装できます。招待ベースのユーザープロビジョニングを提供するために Auth0 Organizations を使用している場合は、通常、IDプロバイダー (IdP) としての Auth0 テナント が管理するフィールドへの変更を制限する必要があります。たとえば、ユーザーが招待の送信先とは異なるメールアドレスを使えないようにするため、メールアドレスの変更は制限したいでしょう。メールアドレスフィールドの変更を制限すれば、会社向けのメールが入力された個人用メールアドレスに送信されてしまうのを防げます。 一方で、Auth0 のデータベース接続で認証するユーザー向けに、いくつかのセルフサービス項目を提供することを検討してもよいでしょう。たとえば、ユーザーが次のことを行えるようにしたい場合があります。
  • メールアドレスを変更する
  • 関連付けられている電話番号を変更する
  • ユーザー名を変更する
  • 規制遵守 (GDPR など) の一環としてアカウントを削除する
  • パスワード変更処理を実行する。これについては通常、パスワードリセットを使用して実装することを推奨しており、一般的にはブランディング: Password Reset Pageで説明されている organization ごとのブランディングを利用します。
セルフサービス機能は通常、Auth0 の外部で実装およびホストする必要があり、高いセキュリティが求められます。

​
エンタープライズ接続

通常、上流のIDプロバイダー (IdP) が IdP 管理のユーザープロファイル属性を処理するため、このユースケースではプロファイル管理がほとんど不要なこともあります。ただし、アプリケーション固有のユーザー属性を使用している場合は、引き続きセルフサービス機能を提供したい場合もあるでしょう。 さらに、organization が Auth0 テナントからユーザーのプロビジョニングを解除できるようにする必要がほぼ確実にあります。Auth0 は、Auth0 の セッションの有効期限が切れた場合を除き、上流の IdP とは通信しません。SSO セッションの有効期限は、ユーザーが削除されるほとんどのシナリオでは長すぎる可能性が高いため、organization 管理者には、ユーザーを個別にブロックまたは削除する手段が必要になります。

​
ソーシャル接続

ソーシャル接続におけるプロファイル管理は、エンタープライズ接続の場合とほぼ同じですが、上流のIdPは特定のorganizationではなく、ソーシャルプロバイダーに関連付けられます。

​
管理

状況によっては、顧客に、その organization に関連付けられたユーザーアカウントを管理するためのアクセス権を付与したいことがあります。これは、ヘルプデスク担当者がユーザーに代わってプロファイル情報を更新したり、ユーザーのアカウントのブロック解除を支援したりするような、ヘルプデスク型のシナリオでよくあります。 Auth0 には標準で、サービスを設定するための Auth0 の主要製品である が用意されており、Auth0 テナントの一般的な管理に使用されます。ただし、顧客に Auth0 テナントの Auth0 Dashboard へのアクセス権を与えるべきではありません。そうすると、すべての organization にまたがるすべてのユーザーを管理できるようになってしまい、望ましくないためです。
Auth0 テナントの Auth0 Dashboard はユーザーアカウントの管理に使用できますが、organization レベルでの分離には対応していません。顧客に Auth0 Dashboard へのアクセス権を与えると、すべての organization にまたがってユーザーを変更できるようになってしまうため、望ましくありません。Auth0 Delegated Admin ダッシュボードは、Auth0 Organization を考慮したユーザーアカウント管理を提供するように設定できますが、ユーザーの メンバーシップ や 招待 の管理には使用できません。
すでに顧客向けのヘルプデスク機能を提供している場合は、Auth0 Management API を使用して Auth0 のユーザーアカウントを管理できます。たとえば、Management API を使用して organization のメンバーを取得 したり、ユーザーが所属する organization を取得 したりできます。まだヘルプデスク機能を提供していない場合は、必要に応じてこの機能を実装する必要があります。