このプロジェクトは、Azure Entra ID を認証に使用した、きめ細やかなロールベースアクセス制御 (RBAC) を備えた FastAPI サービスを実装しています。各ルートにアクセス ポリシーをハードコーディングする代わりに、これらのポリシーはデータベース テーブルに格納されます。これにより、管理者はアプリケーション コードを変更および再デプロイすることなく、ユーザーのアクセス許可を変更できます。システムは Azure Entra ID を使用してユーザーを認証し、JWT クレームからロールを取得します。エンドポイント キーと必要なロールのマッピングは、EndpointPermission SQLModel テーブルに格納されます。承認ロジックの中核は、FastAPI の依存関係として使用される require 関数にあります。この関数は、データベースからエンドポイントに必要なロールを取得し、認証されたユーザーがそれらのいずれかを持っているかどうかを確認します。持っていない場合、403 Forbidden エラーが生成されます。エンドポイントのキー文字列は、ルート定義でハードコーディングされている唯一のリテラルです。極めて重要な点として、これらのアクセス許可を管理するエンドポイント自体が、同じ RBAC メカニズムによって保護されており、管理者のみがアクセス ルールを変更できることが保証されています。管理者がアクセス許可管理エンドポイントへの自身のアクセスを誤って取り消すことを防ぐための保護措置が講じられており、ロールの割り当てが決して空にならないことが保証されています。この記事では、一般的な 2 つの Azure 設定の問題を強調しています。v2 ではなく v1 トークンを使用することによる無効なトークン エラー、およびネストされたグループ メンバーシップが直接割り当てのユーザー ロールに反映されないことです。このプロジェクトでは、承認ロジックを効果的にテストするためのガイダンスも提供しています。テストでは、認証およびセッションの依存関係をオーバーライドして、偽のユーザーとインメモリ SQLite データベースを使用できるため、外部依存関係なしで包括的なテストが可能です。この設計は、ポリシーをデータとして外部化することにより、承認を動的かつ管理可能にし、12 ファクター アプリの原則に準拠しています。著者は、コード ロジックと変更可能なポリシーを区別することを強調しています。