Webアプリケーションのきめ細かい承認

Question

私はC社の社内ユーザーと外部顧客の両方をサポートするC＃.netアプリケーションを用意しています。誰がどのようなリソースにアクセスするかのようにきめ細かい権限を必要とします。だから私は、ロールベースの認可ではなく、リソースベースまたは属性ベースのようなものが必要です。私の心に来る何

のいずれかです：

1. は私の.NETアプリケーションのための私自身の認証メカニズムとSQLテーブルを実装
2. 使用/（XACMLを実施しているソフトウェアなどの標準的なメカニズムを実装

第1の方法の問題点は、集中化も標準化もされておらず、他のシステムがそれを認可に使用できないことです。

2番目のアプローチの問題点は、各リソースに必要な余分な呼び出しのために潜在的に遅い可能性があることです。また、XACMLのような標準的な認可が将来の統合を容易にするための市場のアプリケーションによってどの程度広くサポートされているのかよくわかりません。

したがって、一般的に内部ユーザーと外部顧客の両方にサービスを提供すると思われるWebアプリケーションに対しては、細かい承認のための良いプラクティスは何ですか？

Answer 1

私は間違いなく外部化された承認に行きます。それが遅くなるということではありません。つまり、ビジネスロジックからアクセスコントロールをきれいに分離したことになります。

概要 XACMLは良い方法です。 TCは非常に活発で、ボーイング、EMC、退役軍人管理、Oracle、Axiomaticsなどの企業はすべて積極的なメンバーです。

XACMLアーキテクチャは、あなたが望む性能を発揮できることを保証します。施行（PEP）と意思決定エンジン（PDP）は疎結合しているため、コミュニケーションの方法、使用するプロトコル、複数の決定を使用するかどうかなどを選択できます。あなたのパフォーマンスニーズに合っています。

XACMLのSAMLプロファイルで定義されている標準PDPインターフェイスもあります。これにより、特定のベンダーのソリューションにロックされていない、将来のアクセスを保証するアクセス制御が保証されます。 Webアプリケーション ため

アクセス制御は、あなたは、単にISAPIおよびASP.NETでHTTPフィルタを使用して.NET WebアプリケーションのためのPEPにドロップすることができます。 Axiomaticsはそのために1つの市販品を持っています。

現在の実装 あなたはAxiomaticsの顧客のページをチェックすると、あなたは彼らがペイパル、ベル・ヘリコプターを有し、よりわかります。だからXACMLは確かに現実であり、非常に大規模な展開（何億人ものユーザー）に取り組むことができます。

また、大手の金融サービスプロバイダであるDatev eGは、Axiomaticsの.Net PDP実装をそのサービス/アプリケーションに使用しています。この場合、.Net PDPが組み込まれているため、パフォーマンスが最適です。

そうしないと、.Netのための既製のPEP（例えば、SOAPベースのXACML認証サービスなど）との統合をいつでも選択できます。XACML 昨年7月とパフォーマンスの

高レベルガートナー「触媒」会議で、Axiomaticsは彼らの最新の製品、あなたは「億レコードの挑戦」を取り組むことができますAxiomaticsリバースクエリのリリースを発表しました。 RIAだけでなくデータソースのアクセス制御も対象としています。純粋なXACMLソリューションを使用しているため、他のソリューションとの相互運用が可能です。

実際のところ、Kuppingerコールは非常にすぐにトピックに関するウェビナーを開催します：http://www.kuppingercole.com/events/n10058

をここにもAxiomatics ARQのプレスリリースをご覧ください：http://www.axiomatics.com/latest-news/216-axiomatics-releases-new-reverse-query-authorization-product-a-breakthrough-innovation-for-authorization-services.html

Answer 2

は間違いなく、ドロップでの承認を探してあなたのASP.NETアプリケーション用のモジュール。私はBiTKOOでドロップイン認証システムを実装しているためですが、過去に自宅で認証された認証実装を使用しなければならなかったので、それだけではありません。単一のアプリケーションのための独自の認証システムを構築することは、セキュリティシステムの実装からキャリアを外に出そうとしている場合を除いて、あなたの時間やリソースを有効に活用することにはなりません。

あなたのアプリから承認決定を外部化することは、建築的観点からは良い考えです。 authz決定を外部化することで、Webサービスを停止したり、Webサーバー自体を再構成することなく、アクセス基準を即時に変更する膨大な柔軟性が得られます。 Webフロントエンドをauthzエンジンから分離することで、アプリケーションの負荷とトラフィックパターンに応じてそれぞれを独立してスケーリングすることができ、複数のアプリケーション間でauthzエンジンを共有することができます。

はい、Webアプリケーションにネットワークコールを追加すると、Webレスポンスに何らかのオーバーヘッドが追加されます。これは、権限がまったくない、またはWebサーバー上のローカルデータベースを使用していることに比べます。外部の承認を考慮しない理由であってはなりません。あなたが検討する重大な認可製品は、Web要求ごとに必要なネットワークコールの数を最小限に抑えるためのキャッシュ機能を提供します。

たとえば、BiTKOOのKeystoneシステムでは、ユーザー属性はユーザーセッションごとにWebサーバーにキャッシュできるため、ユーザーログインの確立の一環として、最初のページ要求には実際には1つのバックエンドネットワーク要求が含まれます。後続のページリクエスト（キャッシュされたクレデンシャルの存続期間内に、通常は5分程度）は、authzサービスを再起動する必要なく、Webサーバーで処理できます。これは、クラウドのWebファームで拡張され、XACML標準に基づいて構築されています。