Java权限模型的缺陷 - 编程入门网
| 据返回的结果，应用程序随后查看子资源，对其进行特殊操作。例如，网页可能在加载时查询用户可以访问哪些控制，然后隐藏/禁用那些策略不允许的控制。Java 由于缺乏单个资源模型，无法确定可用的权限，因此没有这样的功能。
返回结果 如在 策略元素 中曾经解释过的一样，Java 缺乏责任的概念来向 PEP 客户端传回有关策略决策的其他信息。这使它无法使用基于 JSE 的策略来控制数据安全性，例如，数据和供安全的一致性 解释了这个问题。 替代方案 如前所述，Java SE 平台安全从未真正从其基于浏览器的基础中成长起来。与权限模型相关的管理和运行时缺陷使其不适合用于企业级应用程序。安全策略和授权是 Java 明显不足的领域。但是，这并没有妨碍其在企业中的应用——相反，大部分大型公司要么内部开发用于授权的解决方案，要么购买第三方的软件。以下部分（虽然不打算涉及 entitlements 市场的形势）将简要介绍可以替代 Java 架构的方法。 Java权限模型的缺陷(5)时间:2011-07-06 developers.sun.com.cn / Denis PilipchukXACML 标准 标准的行业术语已经被整合到 eXtensible Access Control Markup Language (XACML) 标准 中。尽管该标准自身并未提供安全性保护，但其概念是 Fine-Grained Entitlements (FGE) 行业的多个产品的基础，帮助定义了通用的术语和组件。其中很多概念（在以上部门有解释）在 XACML 标准中也有反映。 XACML 自身并未定义 Java 绑定——只有一个 SOAP 配置文件允许发送运行时授权请求。Sun 公司的 XACML 爱好者们早期曾经计划定义一个 J2SE Policy Profile（例如，一个 Java Policy Provider for XACML 策略），但是鉴于过去五年中它没有任何进展，我认为它的有点不值得认真考虑。 相反，不同的提供商已经围绕 XACML 标准开发产品，使其功能可通过其自己的 API 被 Java 应用程序使用，这通常会带来比纯粹的标准简化（而且更容易管理！）的模型。就像其他领域一样，随着时间的流逝，我们将看到市场上现有的各种不同类型的 Java 授权 API 会汇聚成一种行业标准的 Java API。 JSR 115 JSR 115 标准有着漫长而且悲凉的历史，因为尽管供应商在 2003 年就认可了它，但是他们并没有急于使用 JSR 中指定的解决方案来代替他们的特定于平台的解决方案。而且大客户也不急于利用它——实际上，由于 JACC 提供商在接受该标准后不久就加入了 Weblogic，至今还没有一个对此功能的请求或查询。 引起这种冷淡的原因在于该标准本身的目的，以及它提供给公众的工具。JSR 115 专用于修复 EE-to-SE 绑定在授权领域中的一个漏洞；在该领域中，EE 和 SE 机制只是共同存在，但是彼此并未交互。尽管解决了将特定于 EE 的权限带入 SE 域的最初需求，它仍然依靠 SE 权限模型，因此具有以上讨论的所有缺陷。另外，它没有采取任何措施来应对细粒度权利的需求（在上一部分列出）——而这正是公司真正需要的。尽管一些人会辩解说，其机制（比如 ContextHandlers）足够灵活，可以支持 FGE 需求，但是这样一个解决方案的技术和功能有点仍然值得怀疑。这些（以及其他）有关 SE/EE 安全整合的问题在我以前有关此主题的文章中也有涉及，“在 Java EE 和 SOA 环境中使用 JAAS”。 结束语 如上所述，Java 自身的权限模型非常不适合用于大型企业系统。本文并不打算全面地剖析此问题，而只是简要介绍了一些相关的问题。有关细粒度权限的更多信息，建议熟悉 XACML 标准的概念，因为它定义了各方都接受的组件和术语。尽管现在已经有了开源的 XACML 实现和工具包，并不建议立即深入使用它们，因为它们仅是实现了标准，留下了很多以上列出的需要考虑的重要问题。相反，作者强烈建议考 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
