LogtoでRBACをマスターする：包括的な実世界の例

はじめに#

アクセス制御とセキュリティは、ユーザが適切なリソースにアクセスできるようにするという点で、現代のアプリケーションにとって重要な側面であり、Logto の役割ベースのアクセス制御（RBAC）は、開発者がアプリケーションのアクセス制御とセキュリティを効率的に管理する一方で、この記事では実世界の例を用いてLogtoのRBACの強力な特性を探ることで、これらの概念をプロジェクトに理解し適用するのに役立つ方法を提供します。

フロントエンドとバックエンドのコードスニペットの両方を見ることで、アプリケーションスタックにLogtoのRBACを統合する多角的な視点を得ることができます。この記事を読み終えると、プロジェクトのセキュリティとアクセス制御を強化するために、LogtoのRBAC機能を活用できるようになるでしょう。

BookHarberの紹介：オンライン書店の利用ケース#

LogtoのRBAC機能を効果的にデモンストレートするために、実世界の例：BookHarber、オンライン書店を使用します。BookHarberは、顧客とスタッフのための幅広い機能を提供し、シームレスで安全なショッピング体験を確保します。

BookHarberの主な機能には以下のようなものがあります：

1. 書籍の閲覧と購入：ユーザは、様々なジャンルや著者から成る多様なコレクションから、簡単に書籍を検索して購入することができます。
2. 注文管理とロジスティクス追跡：登録済みの顧客は自分の注文を管理し、発送を追跡し、購入に関する最新情報を受け取ることができます。
3. 特別オファーと祝日活動：BookHarberは、特別なイベントや祝日を通じてその顧客基盤に参加して報酬を得るための排他的なディスカウントとプロモーションを提供します。
4. カスタマーサポート：これらに対処するためのサポートチケットを開くことができ、BookHarberスタッフから迅速なアシスタンスを受けることができます。
5. カスタマーマネジメント：異なる役割を持つスタッフメンバーはプラットフォームのさまざまな側面、例えば顧客アカウント、注文処理、問題解決を管理する能力を有しています。

役割#

BookHarberエコシステムでは、いくつかの主要なユーザーロールを特定することができます、例えば：

1. ゲスト：ウェブサイトを閲覧し、書籍を検索し、特別オファーを視聴できる未登録のユーザ。
2. 顧客：書籍を購入し、注文を管理し、ロジスティクスを追跡し、サポートチケットを開くことができる登録ユーザ。
3. ストア管理者：プラットフォームの全体的な管理と運用を監督するスタッフメンバー。フルアクセスを持っています。
4. 書籍マネージャー：書籍とカテゴリ管理を担当するスタッフメンバー。
5. カスタマーサービスエージェント：サポートチケットに対応するスタッフメンバー。
6. サードパーティーロジスティクスプロバイダー：注文の出荷と追跡を管理する外部パートナー。
7. マーケティングスタッフ：BookHarber を宣伝し、特別オファーとイベントを管理する責任を負ったスタッフメンバー。

BookHarber REST API用のスコープ設計#

BookHarberでLogtoのRBACシステムを効果的に実装するためには、各REST APIに対応するスコープを設計する必要があります。スコープは、各APIエンドポイントに対して特定の役割がどの程度のアクセスを持つべきかを定義する権限です。各ユーザーロールに適切なスコープを割り当てることで、ユーザーが彼らの役割に関連するアクションとリソースだけにアクセスできるようにすることができます。

以下のREST APIのためにスコープを設計しましょう：

1. カテゴリAPI：
   • create:categories：POST /categories
   • write:categories：PUT /categories/:id
   • delete:categories：DELETE /categories/:id
   • list:categories：GET /categories
2. 書籍API：
   • create:books：POST /books
   • write:books：PUT /books/:id
   • delete:books：DELETE /books/:id
   • list:books：GET /books
   • read:books：GET /books/:id
3. 顧客API：
   • list:customers：GET /customers
   • write:customers：PUT /customers/:id
   • delete:customers：DELETE /customers/:id
   • read:customers：GET /customers/:id
4. 注文API：
   • create:orders：POST /orders
   • list:orders：GET /orders
   • read:orders：GET /orders/:id
   • write:orders：PUT /orders/:id
5. イベントAPI：
   • create:events：POST /events
   • write:events：PUT /events/:id
   • list:events：GET /events
   • delete:events：DELETE /events/:id
6. 注文トラックAPI：
   • read:orderTracks：GET /orders/:id/tracks
   • create:orderTracks：POST /orders/:id/tracks
   • write:orderTracks：PUT /orders/:id/tracks/:trackId
7. チケットAPI：
   • create:tickets：POST /tickets
   • list:tickets：GET /tickets
   • read:tickets：GET /tickets/:id
   • write:tickets：PUT /tickets/:id

##スコープを役割に割り当てる

各REST APIに適切なスコープを定義したので、これらのスコープをBookHarberエコシステムの各ユーザーロールに割り当てることができます：

"list"と"read"スコープの違いを理解する#

REST API設計とRBACの文脈で"list"と"read"スコープの違いを更に説明するために、オンライン書店、BookHarberを関与する実世界の例を考えてみましょう。

BookHarberには顧客とカスタマーサービスエージェントの2種類のユーザがいるとします。顧客は注文を作成でき、カスタマーサービスエージェントは顧客が注文に関連する手続きを助ける責任があります。このシナリオで**orders** APIリソースに対して"list"と"read"スコープがどのように適用されるかを見てみましょう。

1. List Scopes："list"スコープは、ユーザがシステム内のエンティティのコレクションにアクセスできるようにします。例えば、**list:orders**スコープはユーザがすべての利用可能な注文のリストを取得することを許可します。BookHarberの文脈では、このスコープはストア管理者や他のスタッフメンバーがシステム内のすべての注文の概要を必要とする場合に有用であるでしょう。しかし、カスタマーサービスエージェントはすべての注文一覧にアクセスすることはできません。なぜなら、彼らの役割は個々の顧客が特定の注文をサポートすることにあるからです。
2. Read Scopes："read"スコープは、ユーザが特定のIDを持つ単一のエンティティにアクセスする権限を与えます。例えば、**read:orders**スコープは、ユーザがそのIDによって特定の注文についての詳細情報を表示することを許可します。BookHarberのケースでは、このスコープは特定の顧客の注文に関する情報にアクセスする必要があるカスタマーサービスエージェントにとって理想的です。顧客がサポートチケットを開くと、カスタマーサービスエージェントはチケットに提供された注文IDを使用して、その特定の注文の詳細をアクセスし表示することができます。

所有権理解：なぜ顧客は自分自身の注文について"read"や"list"スコープを必要としないのか#

多くのアプリケーションでは、ユーザが自分自身のリソースに"read"や"list"スコープを明示的に許可することなくアクセスしていることが一般的です。これは、ユーザがこれらのリソースの所有者とみなされ、自然にそれにアクセスできるべきだからです。私たちのBookHarberの例で言えば、顧客は注文を作成できますが、"read:orders"や"list:orders"スコープを持っていません。

所有権概念はREST APIの特定のリソースに対するアクセス制御を定義する上で重要な役割を果たします。ユーザが常に自分自身のリソースにアクセスできることを認識することで、不必要な許可を与えることなく、より効率的で安全なアクセス制御を実装できます。BookHarberの場合、これは顧客がそれ以上のスコープを必要とせずに自分の注文を表示し管理できることを意味します。

これがどのように動作するかを示すために、**GET /orders**エンドポイントを考えてみましょう：

1. ユーザが**list:orders**スコープを持っている場合（例えば、ストア管理者やスタッフメンバー）、彼らはシステム内のすべての注文を表示できます。これにより、役割に必要な注文データの包括的なビューを提供します。
2. ユーザが**list:orders**スコープを持っていない場合（例えば、一般的な顧客）、システムはユーザが所有する注文のみを返します。これにより、顧客は不必要な許可を与えられることなく、自分の注文情報にアクセスすることができます。

この所有権に基づいたアクセス制御を実装することで、APIは促進しながら、セキュリティとユーザ体験を維持するための異なるユーザーコントロールの適切なレベルを提供することができます。BookHarberのシナリオでは、所有権モデルが"read:orders"または"list:orders"スコープなしで顧客が注文情報にアクセスできるようにし、アクセス制御設計を簡略化しユーザ体験を全体的に高めることができます。

Logto Consoleでの設定#

Logtoのコンソールでの設定を完了するための手順は以下の通りです：

1. React 共有サイトアプリケーション（SPA）を作成する： Logto コンソールでReactアプリケーションのためのSPAを設定します。
2. APIリソースを作成する： 識別子**https://api.bookharber.com**を持つ新しいAPIリソースを追加します。
3. リソースのスコープを定義する： 新しく作成したAPIリソースの下で必要なスコープを作成します。
4. 役割を作成しスコープを割り当てる： アプリケーションのユーザロールを定義し、各ロールに適切なスコープを割り当てます。
5. ロールをユーザに割り当てる： ユーザ（スタッフメンバーにとって特に）がそのロールに基づいて正しい権限を持つように、アプリケーションのユーザに関連するロールを割り当てます。

スコープを使用してAPIを保護する#

私たちは例のプロジェクト、BookHarberではバックエンドサービスにExpressを、フロントエンドのウェブページにReactを使用しています。このセクションでは、人気のあるこれらの技術にLogtoのRBACの特性を統合してアプリケーションを保護する方法について簡単に説明します。

まずは公式ドキュメンテーションを要チェック：https://docs.logto.io/docs/recipes/rbac/protect-resource

フロントエンド#

ReactアプリケーションでLogtoを初期化するためのドキュメンテーションはこちら：https://docs.logto.io/docs/recipes/integrate-logto/react/

基本的なセットアップに加えて、設定で"resource"と"scopes"を指定する必要があります：

Logtoを使用してAPIリクエストを行う例は次のとおりです：

Backend#

APIを守るために、こちらを参照：https://docs.logto.io/docs/recipes/protect-your-api/

例のコード（https://docs.logto.io/docs/recipes/protect-your-api/node）に加えて、スコープの検証を追加する必要があります：

おわりに#

LogtoのRBACシステムは、現代のアプリケーションのアクセス制御とセキュリティを管理するための強力なツールです。LogtoのRBAC機能を活用することで、ユーザーが適切なリソースにアクセスできるようにし、機密情報や機能を不正なアクセスから保護することができます。

この記事では、オンライン書店の実世界の例、BookHarberを探し、スコープの設計、ユーザーロールへの割り当て、およびアプリケーションのフロントエンドとバックエンドでのLogtoのRBAC機能の実装方法について説明しました。

これらの概念と技術をプロジェクトに適用することで、アプリケーションのセキュリティとアクセス制御を強化し、シームレスで安全なユーザ体験を提供することができます。あなたがEコマースプラットフォーム、コンテント管理システム、または役割ベースのアクセス制御が必要な他のプロジェクトに取り組んでいたとしても、LogtoのRBACシステムはあなたのアクセス制御のニーズを満たすフレキシブルで効率的なソリューションを提供します。