控制 EJB 调用上传递的安全原则

发布于 2024-08-26 18:01:55 字数 263 浏览 3 评论 0原文

我正在开发一个大型的现有 EJB 1.1 应用程序,该应用程序当前具有自己的安全性,并且没有 EJB 管理的安全性。

我正在尝试逐步转向更标准的解决方案,因此我想开始控制传递给 EJB 的安全原则。我无法更改当前的登录或安全框架,因此我不相信目前可以迁移到 JAAS。

创建 java.security.Principle 后,我应该将其存储在哪里,以便将其传递到我的 ejb 调用中并可从 context.getCallerPrincipal() 获取?

谢谢。

I am working on a large existing EJB 1.1 application that current does its own sercurity and has no EJB managed security.

I am trying to move to a more standard solution in small steps, and so I want to start controlling the security Principle being passed to the EJB. I am not going to be able to change the current login or security framework, so I don't belive I can move to JAAS at the present time.

Once I have created a java.security.Principle where do I store it so it is passed in my ejb calles and avalable from context.getCallerPrincipal()?

Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

烏雲後面有陽光 2024-09-02 18:01:55

Java EE 安全性有点孤注一掷。您应该使用 Java EE 身份验证机制来正确设置安全上下文。如您所见, EJBContext是只读的。

我知道更改安全上下文的唯一标准方法是使用 @RunAs 之类的东西(请参阅示例),但它非常不灵活。您无法动态传递凭据。

有一些不可移植的容器特定机制,例如 Glassfish 有 程序化登录。但即使在这种情况下,您也需要传递用户名/密码,而不能立即更改 Principal

我记得读过一些文章,其中解释了如何使用容器的内部 API 手动设置安全上下文,但它当然是不可移植且不受支持的。

Java EE security is a bit a all-or-nothing thing. You are supposed to use Java EE authentication mechanism to have the security context correctly set. As you can see, the EJBContext that you can obtain through injection is read-only.

The only standard way I'm aware of to change the security context, is using things like @RunAs (See an example), but it's very inflexible. You can not pass credential dynamically.

There are some non-portable container-specific mechanism, for instance Glassfish has ProgrammaticLogin. But even in this case, you need to pass the username/password, you can not just change the Principal on the fly.

I remember reading articles where they explained how to set the security context manually using internal API of the container, but it's of course non-portable and not supported.

肤浅与狂妄 2024-09-02 18:01:55

新的 Java EE 8 中的安全 API 提供一致的安全方法。 SecurityContext 抽象跨越 Servlet 和 EJB 容器,并提供返回用户主体的方法。

在 Java EE 5/6/7 中,servlet 和 EJB 容器实现安全上下文对象的方式不一致。例如,servlet容器提供了一个HttpServletRequest实例,在该实例上调用getUserPrincipal()方法来获取用户Principal,以及EJB容器提供不同名称的 EJBContext 实例,在该实例上调用相同名称的方法。同样,要测试用户是否属于某个角色,请在 HttpServletRequest 实例和 isCallerInRole() 上调用方法 isUserRole()EJBContext 实例上调用。

SecurityContext 为获取此类信息提供了跨 Servlet 和 EJB 容器的一致性。

The new Security API in Java EE 8 provides a consistent approach to Security. The SecurityContext abstraction spans the Servlet and EJB containers and provides methods that return the user principal.

In Java EE 5/6/7 the servlet and EJB containers implement security context objects inconsistently. For example, the servlet container provides an HttpServletRequest instance on which the getUserPrincipal() method is called to obtain the user Principal, and the EJB container provides the differently named EJBContext instance, on which the same named method is called. And likewise, to test if the user belongs to a certain role the method isUserRole() is called on the HttpServletRequest instance and the isCallerInRole() is called on the EJBContext instance.

The SecurityContext provides consistency across the Servlet and EJB container for obtaining this kind of information.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文