4

クレーム ベースの Web サイトのカスタム クレームに基づいて、ドキュメント レベルのアクセス許可を付与したいと考えています。ユーザーは、数百または 1 つのドキュメントを持っている場合があります。カスタム クレームを適用することは良い考えですか? メリットやデメリットは？クレーム セットに追加できるクレームの数に制限はありますか?

よろしくお願いします。

4

1 に答える 1

5

可能ではありますが、通常、クレームを「粗い」ままにしておくことをお勧めします。デフォルトでは、Webアプリでは、クレームセットはリクエストごとに前後に送信されるため（Cookieでシリアル化されるため）、ネットワークを通過するペイロードがかなり大きくなる可能性があります。

Cookieではなく「セッション」を使用するようにWIFを構成することでこれをオーバーライドできますが、サーバー側のセッションのすべての欠点（WebFarmの構成、アフィニティなど）が発生します。

このアプローチで考慮すべきもう1つのことは、STSでのその知識の維持です。頻繁に変更される可能性のあるこれらのクレームを発行するには、かなり多くのルールセットを保持する必要があります。

中央インフラストラクチャSTSでは、これらすべてが潜在的に大規模なアプリセットのボトルネックになるため、絶対に必要ありません。したがって、これらすべてのロジックをRP-STS（およびアプリに関連付けられているSTS）に配置することになります。不可能ではありませんが、おそらく不便です。

通常、「許可」クレームの最大の利点は、承認マネージャーが次のように書くのが難しいことです。

if( PrincipalContainsDocumentClaim( documentYouAreTryingToOpen )
  ShowDocument(documentYouAreTryingToOpen );
else
  AccessDenied(documentYouAreTryingToOpen );

より良いアプローチは、質問に答えることができる承認マネージャーを持つことだと思います。

bool HasAccess( IPrincipal p, string document )

そのコンポーネント内で、クレームセットを使用して、ユーザーがアクセス権を持っているかどうかを判断します。そのロジックには、役割、ユーザー名、およびその他の「上位」の主張（たとえば、所属する組織、所属する国など）の権限へのマッピングが含まれる場合があります。

「許可クレーム」のもう1つの問題は、変更を加えた場合（たとえば、ログインしたユーザーにアクセスを許可した場合）、クレームセットをどのように更新するかということです。logoff-logonする必要がありますが、これは通常、優れたユーザーエクスペリエンスではありません。

于 2010-09-10T12:43:26.360 に答える