EJB 3.1 - javax.security.auth的实现

Question

3

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

我了解到安全应该由容器提供者实现，Bean提供者可以使用简单的注释（如@javax.annotation.security.RolesAllowed、@PermitAll等）在他的Bean中使用它，这是JSR推荐的做法。

我的问题是：这意味着安全性不能在没有部署到容器的情况下进行测试。是否有一种方法可以使用外部第三方实现的javax.security，在测试中从中注入Bean，以便传播和测试安全性？

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

附言：我只是想检查这是否可能，如果可能，它可能会为其他开发开辟道路。我了解到，这种测试可以通过在类似OpenEJB或Arquillian的嵌入式容器中部署Bean来轻松完成。

- Bala

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- David Blevins · Accepted Answer

所有这些都涉及到很多的管道工程。其中比较棘手的部分包括：

处理注释并遵守非继承和覆盖规则（不涉及xml覆盖）
确保注释不被滥用或错误应用
尊重xml并覆盖注释数据
将“roles allowed”与声明的“roles”映射（有一定的间接性）
将所有元数据作为格式正确的权限字符串添加到JACC提供程序中
通过适当配置的JAAS LoginModule处理登录
一些创造性的代码，以将JAAS与JACC集成（没有标准方法可用）
通过doAs调用或ThreadLocal跟踪您的主题
代理所有对象，以便您可以在方法实际调用之前执行授权检查
更改使用@RunAs注释的方法的安全上下文，并确保RunAs角色是已声明的角色
处理EJBContext.getCallerPrincipal()（一个Subject具有许多Principal对象，因此您必须选择一个对象返回并确保您可以一致地选择相同的对象）
将EJBContext.isCallerInRole(String)与JACC提供程序连接起来
确保在处理登录失败、授权失败和各种其他情况时使用正确的异常类

那么这就是容器所做的事情。JAAS和JACC所做的工作确实非常小。至少没有那么注重细节。

这里没有什么可以“注入”的，如你所希望的那样。安全性实际上是一个环绕建议。

表面上看，基于注释的安全似乎非常简单。但是，当您探索所有组合、注意事项和条件时，它确实会增加。我记得上面所有的细节，因为我在第一次实现它们时都搞错了。:)谢天谢地有TCKs。

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

如果您确实有特定的测试方式，最聪明的做法是参与OpenEJB或Arquillian。

OpenEJB中所有最酷的功能都来自用户的疼痛和人们向我们描述“我这样做会受到伤害”的方式。我们喜欢它。这是一个很好的功能来源，也是获得新贡献者的好方法，还是证明可能对将其纳入规范中有益的想法的绝佳方式（例如EJB 3.1中的嵌入式EJBContainer API）。

我无法强调参与创新而不是尝试规避它的重要性。如果某些方法不能满足您的需求，请要求更好的方法。

最后一句话更多地是针对整个世界的 :)