JBoss 数据库身份传播?

发布于 2024-10-06 16:20:42 字数 238 浏览 0 评论 0原文

我读过 IBM 的 WebSphere 如何将用户身份传播回后端数据库 (http://www.ibm.com/developerworks/websphere/techjournal/0506_barghouthi/0506_barghouthi.html)。 JBoss有类似的功能吗?理想情况下,我希望能够使用 SPNEGO 登录到我的 JBoss 应用程序,并使用 Kerberos 或其他一些机制将该身份传播回 PostgreSQL 数据库。这可能吗?

I've read how IBM's WebSphere can propagate the identity of a user back to a backend database (http://www.ibm.com/developerworks/websphere/techjournal/0506_barghouthi/0506_barghouthi.html). Does JBoss have similar functionality? Ideally, I'd like to be able to login to my JBoss application using SPNEGO and propagate that identity back to a PostgreSQL database using Kerberos or some other mechanism. Is this possible?

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

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

发布评论

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

评论(1

夜空下最亮的亮点 2024-10-13 16:20:42

您链接到的文章可用于此目的,但有一些注意事项。

让应用服务器使用 Kerberos 作为不同用户重新进行身份验证可能不太现实。根据我对 Kerberos 的了解(诚然有限),它的设计使得最终用户交互需要进行实际的身份验证握手。用户通过 HTTP 与应用程序服务器进行握手——实际上并没有一种机制可以要求他们与数据库本身重新进行身份验证。

不过,如果您的应用服务器以超级用户身份执行与数据库的连接,您可以使用它们的钩子向 PostgreSQL 发出“SET SESSION AUTHORIZATION TO ...”命令。这实际上并不重新进行身份验证,只是暂时更改会话授权角色。

您还可以使用无数“在数据库中存储一些会话信息”解决方案(自定义变量、PL/Perl 等全局变量)之一,并使用它们的钩子来处理它。这实际上就是他们的 Oracle 解决方案似乎要做的事情,它设置客户端标识符,其中 iirc 只是 dbms_util 中某处的全局变量,该变量包含在显示当前会话的视图中(并且 postgresql 9.0 有一个执行相同角色的“应用程序名称”)

The article you've linked to could be used for that, but there are some caveats.

Having the app server re-authenticate as different users using Kerberos is probably not realistic. From my knowledge of Kerberos (admittedly limited), it is designed so that end-user interaction is required to do an actual authentication handshake. The user does the handshake with the app server over HTTP-- there isn't really a mechanism for asking them to re-authenticate with the DB itself.

You could use their hooks to issue "SET SESSION AUTHORIZATION TO ..." commands to PostgreSQL, though, if your app server performs its connections to the DB as a superuser. That doesn't actually re-authenticate, just changes the session authorisation role temporarily.

You could also use one of the myriad "store some session information in the DB" solutions (custom variables, PL/Perl etc global variables) and use their hooks to work with that. This is actually what their Oracle solution seems to do, it sets the client identifier which iirc is just a global variable in dbms_util somewhere that is included in views showing current sessions (and postgresql 9.0 has an "application name" that performs the same role)

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