Web应用程序的细粒度授权

时间:2011-11-02 22:04:56

标签: authorization xacml abac

我有一个C#.net应用程序,它为公司的内部用户和外部客户提供服务。我需要做一些细粒度的授权,比如访问哪些资源。所以我需要基于资源或基于属性的东西,而不是基于角色的授权。

我想到的是:

  1. 为我的.net应用程序实现自己的授权机制和sql表
  2. 使用/实施标准机制,如已实施XACML的软件(例如Axiomatics)
  3. 第一种方法的问题在于它不是集中式的,也不是标准的,因此其他系统不能将其用于授权。

    第二种方法的问题是它可能更慢(由于每个资源需要额外的调用)。此外,我不确定市场上的应用程序是否支持像XACML这样的标准授权有多广泛,以便于将来的集成。

    因此,对于应该为内部用户和外部客户提供服务的Web应用程序,通常细粒度授权的良好做法是什么?

2 个答案:

答案 0 :(得分:8)

我肯定会去外部授权。这并不意味着它会变慢。这意味着您将访问控制与业务逻辑完全分开。

<强>概述 XACML是一个很好的方法。 TC非常活跃,波音,EMC,退伍军人管理局,甲骨文和Axiomatics等公司都是活跃会员。

XACML架构可确保您获得所需的性能。由于执行(PEP)和决策引擎(PDP)松散耦合,您可以选择他们如何沟通,他们使用什么协议,是否使用多个决策等...这意味着您可以选择进行集成符合您的性能需求。

在XACML的SAML配置文件中还定义了标准PDP接口。这可以保证您在未遇到任何特定供应商解决方案的情况下实现“面向未来”的访问控制。

对于webapps的访问控制 您可以使用ISAPI和ASP.NET中的HTTP过滤器简单地为.Net webapps插入PEP。 Axiomatics有一个现成的。

当前实施 如果您查看Axiomatics的客户页面,您会看到他们有Paypal,贝尔直升机等。因此XACML确实是现实,它可以解决非常大的部署(数亿用户)。

此外,领先的金融服务提供商Datev eG正在为其服务/应用程序使用Axiomatics的.Net PDP实施。由于.Net PDP是嵌入在这种情况下的,因此性能是最佳的。

否则,您始终可以从.Net的现成PEP中选择与任何PDP集成 - 例如基于SOAP的XACML授权服务。

XACML的高性能 去年7月,在Gartner“Catalyst”会议上,Axiomatics宣布发布他们的最新产品Axiomatics Reverse Query,帮助您应对“十亿记录挑战”。它针对数据源和RIA的访问控制。它使用纯XACML解决方案,以便与其他解决方案保持互操作。

事实上,Kuppinger Cole将很快主持关于该主题的网络研讨会: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

答案 1 :(得分:3)

绝对要为您的ASP.NET应用程序寻找一个直接授权模块。我不只是这么说,因为我在BiTKOO实现了drop-in auth系统,但是因为我过去不得不使用自己生成的auth实现。为单个应用程序构建自己的授权系统实际上并不能很好地利用您的时间或资源,除非您打算从实施安全系统开始。

从架构的角度来看,从您的应用程序外部化授权决策是个好主意。外部化authz决策为您提供了极大的灵活性,可以即时更改访问条件,而无需关闭Web服务或重新配置Web服务器本身。通过将Web前端与authz引擎分离,您可以根据应用程序的负载和流量模式独立扩展每个引擎,并允许您跨多个应用程序共享authz引擎。

是的,与没有授权或使用Web服务器上的本地数据库相比,向Web应用程序添加网络调用会增加Web响应的开销。这不应成为不考虑外部授权的理由。您考虑的任何严格授权产品都将提供某种缓存功能,以最大限度地减少每个Web请求甚至跨多个Web请求的每个用户会话所需的网络调用数。

例如,在BiTKOO的Keystone系统中,用户属性可以按用户会话缓存在Web服务器上,因此在建立用户登录时,第一页请求中实际上只涉及一个后端网络请求。后续页面请求(在缓存凭据的生命周期内,通常为5分钟左右)可以由Web服务器处理,而无需再次访问authz服务。这在云网络农场中很好地扩展,并且基于XACML标准。

相关问题