Skip to main content
ロールベースのアクセス制御 (RBAC) が必要になる理由と、それをでどのように利用できるのか、例を見てみましょう。 ここで、あなたが非営利団体向けに B2B の SaaS を提供している企業だとしましょう。あなたの製品では、非営利団体が潜在的な寄付者向けの商品を作成、管理、販売促進できます。あなたのアプリケーションにはいくつかのモジュールがあり、そのうち 2 つは次のとおりです。
  • 非営利団体がポップアップの T シャツショップを効率的に立ち上げ、売上を管理できるギフトショップ POS モジュール。
  • 非営利団体が寄付者向けのニュースレターを作成し、配信できるマーケティングモジュール。
Auth0 を使って、非営利団体の顧客がアプリケーション内の各機能へアクセスできる範囲を制御したいと考えています。RBAC がなければ、非営利団体の従業員やボランティアは全員、アプリケーションのすべての機能にアクセスできてしまいます。これは理想的ではありません。特に、そのうちの 1 団体が動物保護団体で、各ボランティアが自分の担当分野に関する知識しか持っていないような場合はなおさらです。 そこで、代わりに RBAC を実装し、ギフトショップ POS モジュールのユーザーに必要ないくつかの権限を作成します。
  • read:catalog-item
  • read:customer-profile
  • create:invoice
さらに、管理しやすくするために、Gift Shop Manager というロールを作成し、そのロールにこれらの権限を追加します。 同様に、マーケティングモジュールのユーザー向けの権限も作成します。これには次のものが含まれます。
  • create:newsletter
  • edit:newsletter
  • delete:newsletter
  • send:newsletter
  • edit:distribution-list
そして、Newsletter Admin というロールを作成し、そのロールにこれらの権限を追加します。 これで、動物保護団体がポップアップの T シャツショップを運営するためにボランティアの Astrid を迎え入れたとき、Astrid に Gift Shop Manager のロールを割り当てることができます。このロールを Astrid に割り当てると、そのロールに割り当てたすべての権限が Astrid に付与されます。Astrid はニュースレター配信について何も知らず (しかもメールもあまり得意ではない) ため、Newsletter Admin ロールは割り当てません。したがって、彼女がマーケティングモジュールにアクセスすることはありません。 もう少し技術的な観点で見ると、Astrid があなたの製品にログインすると、Auth0 は彼女を認証・認可し、返されたに権限を含めます。その後、あなたの製品はトークンを確認し、Astrid にどのモジュールを表示するかを判断します。 Auth0 の RBAC を使えば、個別の認可システムを構築・保守する必要がなくなり、代わりに認可時にすでに受け取っているトークンを利用できます。また、Astrid が引っ越したり、ギフトショップの運営をやめて里親プログラムの調整を担当したくなったりした場合は、彼女からGift Shop Manager ロールを削除し、新しいロールを割り当てるだけで済みます。 さらに、すべての顧客についてロールや権限を維持するのが煩雑になってきた場合は、Auth0 API を使って、顧客自身が自分たちの RBAC を管理できるモジュールを製品内に作成することもできます。これにより、責任を軽減し、人件費を削減できます。