プリンシパルをリソースコンテナから分離する

リソース階層を設計する際、特に消費者向けアプリケーションによくある傾向の 1 つは、顧客のユーザー ID を顧客アカウント内のリソースのコンテナとして使用することです。

この戦略はアンチパターンとして扱うことをおすすめします。これは、機能が豊富なアプリケーションでは、アクセスを他のユーザーに委任する傾向が自然にあるためです。たとえば、他のユーザーがアカウントリソースを共有できる「ファミリー」アカウントを導入することを選択できます。同様に、企業の顧客は、複数の従業員をアカウントの一部の運営者に指定したい場合があります。また、アカウントの所有権を別のユーザーに移したり、複数のアカウントのリソースを統合したりする必要が生じる場合もあります。

ユーザー ID をアカウントのリソースコンテナとして使用すると、以前のシナリオを実現するのが難しくなります。さらに憂慮すべき点は、この方法で他のユーザーにアカウントコンテナへのアクセス権が付与されると、ジェーンの電子メールやログイン認証情報の変更など、ユーザー ID 自体を変更するためのアクセス権限を誤って付与されてしまう可能性があることです。

そのため、可能な場合は、プリンシパルをリソースコンテナから切り離し、「管理者権限」や「所有権」などの概念を使用してプリンシパルをリソースコンテナから分離し、プリンシパル間の接続をモデル化するのがより回復力のあるアプローチです。

既存のアプリケーションではこのような切り離されたモデルを実現できない場合は、承認モデルを設計する際にできる限りそれを模倣することを検討することをおすすめします。たとえば、ユーザー ID、ログイン資格情報、および所有するリソースをカプセル化する Customer という名前の 1 つの概念だけを持つアプリケーションは、これを Customer Identity の 1 つの論理エンティティ (名前、電子メールなどを含む) を含む認可モデルにマッピングできます。 Customer Resources または Customer Account 用の別個の論理エンティティは、それらが所有するすべてのリソースの親ノードとして機能します。両方のエンティティは同じ Id を共有できますが、Type は異なります。