3

据我了解 javax.security.auth 是一个用于身份验证和授权的 API。

我知道安全性应该由容器提供者实现，并且 bean 提供者可以按照 JSR 的建议在他的 bean 我的简单注释（等）中@javax.annotation.security.RolesAllowed使用它。@PermitAll

我的问题：这仅仅意味着如果不部署在容器中就无法测试安全性。有没有办法使用 javax.security 的外部第三个实现，它可以以某种方式从测试中注入到 bean 中，也可以从中传播和测试安全性？

这几乎是一种类似的方法，我们使用该方法将 JPA 实现或外部事务管理器从单元测试注入到 bean 中进行测试。

PS：我只是想检查一下这是否可能，如果可能的话，它可能会为其他一些开发开辟道路。我知道可以通过将 bean 部署在 OpenEJB 或 Arquillian 等嵌入式容器中轻松完成此测试。

4

1 回答 1

4

所有这些都涉及到很多管道。更棘手的部分是：

  • 处理注释并尊重非继承和覆盖规则（不是指 xml 覆盖）
  • 确保注释不会被滥用或错误应用
  • 尊重 xml 并覆盖注释数据
  • 将“允许的角色”与声明的“角色”映射（存在一定程度的间接性）
  • 将所有元数据作为格式正确的权限字符串添加到 JACC 提供程序
  • 通过正确配置的 JAAS LoginModule 处理登录
  • 一些将 JAAS 与 JACC 集成的创意代码（没有标准的方法来做到这一点）
  • 通过doAs电话或ThreadLocal
  • 代理所有对象，以便您可以在实际调用方法之前进行身份验证检查
  • 更改使用 @RunAs 注释的方法的安全上下文并确保 RunAs 角色是已声明的角色
  • 处理EJBContext.getCallerPrincipal()（aSubject有很多Principal对象，因此您必须选择一个返回并确保您可以始终选择相同的一个）
  • 连接EJBContext.isCallerInRole(String)到 JACC 提供程序
  • 确保在处理登录失败、授权失败和各种其他情况时使用正确的异常类

这就是容器的作用。JAAS 和 JACC 所做的工作真的很小。当然至少没有那么注重细节。

这些都不能像您希望的那样真正“注入”。安全性实际上是一种围绕建议。

从表面上看，基于注释的安全性之类的东西看起来非常简单。然而，当你探索所有的组合、注意事项和条件时，它确实加起来了。我记得上面所有这些细节，因为当我第一次必须实施它们时，我把它们全都弄错了。:) 谢天谢地 TCKs。

我不建议尝试制作自己的安全测试框架。

如果您确实希望以特定的方式进行测试，那么最明智的做法就是参与 OpenEJB 或 Arquillian。

OpenEJB 中所有最酷的特性都来自于用户的疼痛和痛苦，以及人们向我们描述的“当我这样做的时候很痛”。我们喜欢它。它是功能的重要来源，是获得新贡献者的好方法，也是证明可能有利于将其引入规范的想法的绝妙方法（例如 EJB 3.1 中的 Embedded EJBContainer API）。

我怎么强调参与创新而不是试图绕过它是多么重要。如果某样东西不能满足你的需求，那就要求更好。

最后的声明更针对整个世界:)

于 2012-01-10T09:55:18.033 回答