EJB3& JAAS 主题/主体如何从 servlet 容器传播到 EJB 层？
我试图了解 JAAS 主体如何从 Web 层传播到业务/EJB 层。
我读过，如果角色/领域是在 login-config & 中配置的， web.xml 的 security-context 那么 servlet 容器也会透明地将经过身份验证的主体传递到 EJB 层。
两个问题
1.) 首先&更重要的是这是真的吗？无需开发商的任何干预！
2.) 其次，知道它在幕后是如何工作的。
I'm trying to understand how the JAAS principal propagates to the Business/EJB tier from web tier.
I've read that the if the roles/realm is configured in login-config & security-context of web.xml then the servlet container will also transparently pass the authenticated principal to the EJB Tier.
Two questions
1.) First & more importantly is that true ? Without any intervention from the developer !
2.) And secondly any idea how that works under the hood.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在 EJB 调用中会传播各种“上下文”信息，一旦您进入 EJB 层并开始执行 EJB-EJB 调用，事务就是一个例子。有些容器也允许您创建自己的此类上下文对象。
线程本地存储可以在进程内使用，但通常只是假设容器负责并且可以做正确的事情 - 实际技术是特定于实现的。
There are various "context" pieces of information that get propagated in EJB calls, once you get inside the EJB layer and start doing EJB-EJB calls then Transactions would be an example. Some containers allow you to create your own such context objects too.
Thread-local storage can be used within a process, but generally just assume that the container is in charge and can do the right thing - the actual technique is implementation specific.
关于你的第一个问题——是的。
关于你的第二个问题——你熟悉 EJB3 拦截器吗？
容器使用 bean 的“拦截代码”创建代理对象，
此外，容器还可以跟踪方法和 bean 类上的其他注释，例如，检测 @PostConstruct 注释。
使用角色定义，它可以检查配置（旧版本的 jboss 中的 login-config.xml 或 JBoss AS 7 中的独立配置中的standalone.xml）并了解每个角色的定义是什么。
JAAS 按顺序使用为您提供身份验证和授权的抽象层。
JAAS 背后的概念之一是登录模块 - 它为您提供“特定于协议”的代码来处理实际的授权和身份验证。
例如，我以这种方式使用 Krb5LoginModule 来使用 kerberos。
Regarding your first question - yes.
Regarding your second question - are you familiar for example with EJB3 interceptors?
The container create proxied objects with "interception code" for the beans,
and in addition the container can track other annotations on the methods and the bean class,
for example, to detect the @PostConstruct annotation.
Using the role definition, it can check the configuration
(either login-config.xml at older versions of jboss, or standalone.xml in JBoss AS 7 at standalone configuration) and understand what is the definition per each role.
JAAS is used in order to provide you abstraction layer over authentication and authorization.
One of the concepts behind JAAS is login module - it provides you "protocol specific" code that takes care of the actual authorization and authentication.
For example, I'm using in this way Krb5LoginModule to use kerberos.
正如您大部分猜测的那样，从 Web 层传播到 EJB 层的
Principal是通过 web.xml 中的login-config配置的。它的实现方式取决于实现。用户/组数据也依赖于实现，并且被配置为应用服务器的一部分。
然而，实现此目的的方法之一是通过 JASPIC 提供程序的实现，这是获取
Principal的标准方法。与 WEB-INF/web.xml 提供的标准表单登录、基本身份验证或证书身份验证相比，使用此方法可以让您拥有不同的身份验证路径，但工作量要多一些。JASPIC 身份验证路径允许更复杂的场景，例如基于标头的身份验证或双因素或 OpenID。用户数据库“通常”不需要与应用程序服务器中的数据库绑定。我说“通常”是因为 WebSphere Application Server 将身份验证与服务器上配置的用户联系起来。
The
Principalpropagates to the EJB tier from web tier is configured through thelogin-configin the web.xml as you had surmised for the most part.How it is implemented is implementation dependent. The user/group data is also implementation dependent and is configured as part of the application server.
However, one of they ways this is done is through an implementation of the JASPIC provider which is a standard way of obtaining the
Principal. Using this allows you to have a different authentication path compared to the standard form login, basic authentication or certificate authentication provided byWEB-INF/web.xmlbut it is a little bit more work.JASPIC authentication paths allow more complex scenarios such as header based authentication or two-factor or OpenID. The user database "usually" does not need to be tied to the one in the application server. I say "usually" because WebSphere Application Server ties the authentication to a user configured on the server.