会社の内部ユーザーと外部顧客の両方にサービスを提供する C# .net アプリケーションがあります。誰がどのリソースにアクセスするかなど、きめ細かい承認を行う必要があります。したがって、ロールベースの承認ではなく、リソースベースまたは属性ベースのようなものが必要です。
私の頭に浮かぶのは、次のいずれかです。
最初の方法の問題点は、集中化も標準化もされていないため、他のシステムが認証に使用できないことです。
2 番目のアプローチの問題点は、(リソースごとに余分な呼び出しが必要なため) 遅くなる可能性があることです。また、将来の統合を容易にするために、市場のアプリケーションで XACML のような標準認証がどの程度サポートされているかもわかりません。
では、一般的に、内部ユーザーと外部顧客の両方にサービスを提供することになっている Web アプリケーションのきめの細かい承認の良い方法は何ですか?
私は間違いなく外部化された承認に行きます。遅くなるというわけではありません。これは、アクセス制御をビジネス ロジックから明確に分離したことを意味します。
概要 XACML は良い方法です。TC は非常に活発で、Boeing、EMC、退役軍人局、Oracle、Axiomatics などの企業がすべて活発なメンバーです。
XACML アーキテクチャは、必要なパフォーマンスを実現できることを保証します。施行 (PEP) と意思決定エンジン (PDP) は疎結合であるため、通信方法、使用するプロトコル、複数の意思決定を使用するかどうかなどを選択できます。パフォーマンスのニーズに適合します。
XACML の SAML プロファイルで定義されている標準の PDP インターフェイスもあります。これにより、特定のベンダー ソリューションに縛られることのない「将来性のある」アクセス制御が保証されます。
Web アプリケーションのアクセス制御 ISAPI および ASP.NET で HTTP フィルターを使用して、.Net Web アプリケーションの PEP を簡単にドロップできます。Axiomatics には、そのための既製品があります。
現在の実装 Axiomatics の顧客ページを確認すると、Paypal、Bell Helicopter などがあることがわかります。したがって、XACML は確かに現実のものであり、非常に大規模な展開 (数億のユーザー) に取り組むことができます。
また、主要な金融サービス プロバイダーである Datev eG は、サービス/アプリに Axiomatics の .Net PDP 実装を使用しています。その場合、.Net PDP が組み込まれているため、パフォーマンスが最適化されます。
それ以外の場合は、SOAP ベースの XACML 認証サービスなど、任意の PDP と統合する .Net 用の市販の PEP からいつでも選択できます。
XACML による高レベルのパフォーマンス 昨年 7 月の Gartner "Catalyst" カンファレンスで、Axiomatics は最新の製品である Axiomatics Reverse Query のリリースを発表しました。これは、データ ソースと RIA のアクセス制御を対象としています。他のソリューションとの相互運用性を維持できるように、純粋な XACML ソリューションを使用します。
実際のところ、Kuppinger Cole はこのトピックに関するウェビナーを間もなく開催します: http://www.kuppingercole.com/events/n10058
こちらの Axiomatics ARQ プレス リリースもご覧ください。 services.html
Definitely look for a drop-in authorization module for your ASP.NET application. I'm not just saying that because I implement drop-in auth systems at BiTKOO, but because I have had to work with home-grown auth implementations in the past. Building your own authorization system for a single application really is not a good use of your time or resources unless you intend to make a career out of implementing security systems.
Externalizing the authorization decision from your app is a good idea from an architectural standpoint. Externalizing the authz decision gives you an enormous amount of flexibility to change your access criteria on the fly without having to shut down your web service or reconfigure the web server itself. Decoupling the web front-end from the authz engine allows you to scale each independently according to the load and traffic patterns of your application, and allows you to share the authz engine across multiple apps.
Yes, adding a network call to your web app will add some overhead to your web response compared to having no authorization at all or using a local database on the web server. That shouldn't be a reason not to consider external authorization. Any serious authorization product you consider will provide some sort of caching capability to minimize the number of network calls required per web request or even per user session across multiple web requests.
In BiTKOO's Keystone system, for example, the user attributes can be cached on the web server per user-session, so there's really only one back-end network request involved on the first page request as part of establishing a user login. Subsequent page requests (within the lifetime of the cached credentials, usually 5 minutes or so) can be handled by the web server without needing to hit the authz service again. This scales well in cloud web farms, and is built on XACML standards.