XACML 作为现有应用程序的演变步骤
我已经开始对 XACML 和外部授权进行一些研究。现在我有一个使用 RBAC 模型的现有应用程序。然而，该实现有很多缺点（角色不容易定义，角色太粗粒度）。
XACML 是一个不错的替代方案吗？是否有任何现有应用程序已从 RBAC 源切换到 XACML？有什么缺点吗？
I've begun doing some research on XACML and external authorization. Right now I have an existing application which utilizies an RBAC model. However the implementation has a lot of shortcomings (roles can't be easily defined, roles are too coarsly grained).
Is XACML a good alternative to look at? Are there any exisitng applications which have switched to XACML from an RBAC origin? Are there any shortcomings?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
免责声明：我是 IBM 的一名开发人员，我致力于开发广泛使用 XACML 的产品（Tivoli Security Policy Manager）。我对 XACML 有点偏见。
我认为 XACML 是一个很好的替代方案，主要是因为它可以支持几乎任何安全模型。我建议在 XACML 中对现有 RBAC 解决方案进行建模（请参阅 配置文件），然后将其扩展以在您的业务需求需要时包含更细粒度的访问控制。
将授权代码外部化到策略中具有额外的优势，即无需重新编译即可修改应用程序的安全模型。
不幸的是，我不知道任何具体的例子，至少是我可以公开谈论的例子。有一个 IBM 内部项目分配了一个月的时间来实现其授权模块，但通过使用我们的 XACML 实现将其外部化，一周内就完成了。这显然与您的示例不同，因为它是一个“绿色领域”开发项目，但强调您正在考虑的一般方法有很多好处。
Disclaimer: I'm a developer for IBM, and I work on our product that uses XACML extensively (Tivoli Security Policy Manager). I'm a little biased towards XACML.
I think XACML is a great alternative, mainly because it can support almost any security model. I'd suggest modelling your existing RBAC solution in XACML (see the profile), then extending it to include finer-grained access control where your business requirements demand it.
Externalizing your authorization code into policy has the added advantage of being able to modify your application's security model without recompiling it.
Unfortunately I'm not aware of any particular examples, at least ones that I can talk about publicly. There is an internal IBM project that allocated a month for implementing their authorization module, but got it done in a week by externalizing it using our XACML implementation. This is obviously different to your example as it was a "green fields" development project, but highlights that there are benefits to be had with the general approach you're considering.
我是 WSO2 的安全架构师，该公司开发了 WSO2 Identity Server，这是一个开源身份和权利管理服务器，具有 XACML 支持。
我也相信 XACML 是从应用程序代码外部化授权逻辑的一个很好的替代方案。我们最近与少数客户合作 [其中一位是财富 100 强] - 从不同的专有授权规则转向 XACML。
I am the security architect at WSO2 - which develops WSO2 Identity Server, an open source Identity and Entitlement management server, with XACML suport.
I too believe XACML is a good alternative to externalize authorization logic from the application code. We recently worked with few customers [one of them is among Fortune 100] - moving to XACML from different proprietary authorization rules.
我分别同意 IBM 和 WS02 同行的观点。我为公理学工作。我们专注于基于 XACML 的授权。
我们有客户从 RBAC 迁移到 ABAC。有些人决定使用 XACML 的 RBAC 配置文件作为中间步骤 (http://docs.oasis-open.org/xacml/3.0/xacml-3.0-rbac-v1-spec-cd-03-en.html)。有趣的是，您可以使用现有的 RBAC 基础设施来构建 ABAC。
到目前为止我们还没有看到任何缺点。如果说有什么不同的话，那就是客户很快就能看到 XACML 的投资回报率：它更便宜、更灵活。您可以使用多种实现（您可以将 IBM、WS02 和 Axiomatics 混合在一起，它仍然可以工作）并且得到业界的大力支持。
查看 XACML TC 页面了解更多信息：http://www.oasis-open.org/委员会/xacml/
I agree with my counterparts from IBM and WS02 respectively. I work for Axiomatics. We focus exclusively on authorization based on XACML.
We have customers who moved from RBAC to ABAC. Some decided to use the RBAC profile for XACML as a middle step (http://docs.oasis-open.org/xacml/3.0/xacml-3.0-rbac-v1-spec-cd-03-en.html). What's interesting is that you can use your existing RBAC infrastructure to build ABAC on top.
We haven't seen any shortcomings as yet. If anything, customers quickly see the ROI with XACML: it's cheaper and more flexible. You can use multiple implementations (you could mix IBM, WS02, and Axiomatics together and it would still work) and there is strong support from the industry.
Check out the XACML TC page for more info: http://www.oasis-open.org/committees/xacml/