ASP.NET Web API を使用してシングルページ Web アプリケーション (SPA) およびその他の潜在的なネイティブ モバイル アプリ プラットフォームをサポートする分散アプリケーションを作成しています。現在のアーキテクチャでは、クライアントが WebAPI にアクセスするために使用する認証トークンを提供する STS としてThinktecture Identity Serverを使用しています。バックエンドには、WebAPI とは別のアプリ ドメインで WCF サービスによって公開される永続性とビジネス ロジックがあります。WebAPI はサービス層を呼び出してデータにアクセスし、ドメインでアクションを実行します。
私の質問は Authorization に関するものです。私はクレーム ベースの承認を使用し、WCF で公開されたビジネス レイヤーからユーザーに関して保持されているドメイン データからクレームのリストを拡張できます。しかし、どこで承認を行う必要がありますか? .NET 4.5 では、ASP.NET に拡張可能なモデルが追加され、ClaimsAuthorizationManager を使用して、承認ロジックをコントローラーから別の承認モジュールに分離できるようになりました。また、Thinktecture.IdentityModel私のWebAPIアプリケーション内でこれを行うためのすべての配管を提供するという非常に良い仕事をします. ただし、承認ロジックは WCF サービスの背後にあるビジネス層に配置する必要があり、クライアント向けの WebAPI にこれを強制するべきではないと考えずにはいられません。WCF ベースのビジネス レイヤーを使用するために、他のクライアント向けのホストされたアプリを必要とする場合は、セキュリティ コードも実装する必要があります。マイナス面としては、承認されていないリクエストが拒否される前に、アプリケーションのかなり奥まで到達することを意味します。
質問: ASP.NET でクレーム ベースの承認機能を使用する必要がありますか?それとも、WCF サービスの背後にあるビジネス レイヤーに承認をラップする必要がありますか?