Java EE - 从类获取单元/节点信息

发布于 2024-10-19 01:06:57 字数 1362 浏览 3 评论 0原文

我需要从 Java Enterprise 应用程序与 C/C++ 进行交互。我想编写一个能够收集 Node/Cell 信息的类,可能还有有关应用程序部署位置的任何其他信息,因此我可以从 C++ 追溯到调用来源的文件系统中的 JAR(权威)。是否有一个特定的 Java 库可供我使用来提供有关应用程序的此类信息?理想情况下,会发生的情况是:(我们称之为 EnvProvider)

  1. Java 应用程序调用 EnvProvider
  2. EnvProvider 收集有关调用它的 Java 应用程序的信息
  3. EnvProvider 调用包装的 C++(也许是 CORBA、SOAP?)并将此信息传递
  4. 给 C++ 跟踪文件系统到调用应用程序,检查声称的应用程序调用来自的实际 JAR 文件。

这听起来微不足道(这里仅概述了 4 个步骤),但从我迄今为止的研究来看,似乎没有好的方法可以从 Java 应用程序本身获取有关 Java 应用程序的足够信息。我所说的“足够”信息是指足以为 C++ 提供足够的信息来遍历文件系统并找到已部署的 EAR、JAR、WAR。

如果您能提供任何信息,我们将不胜感激!

问候

Chad

* 编辑 *

Kim,谢谢您的回复。让我解释一下为什么我需要获取这个特定的跟踪。

我正在开发/使用一个用 C/C++ 编写的加密库。它们是我的前任在这里(我工作的地方)编写的,并且经过了很好的测试。然而,它们提供的不仅仅是加密,而且其中包含的算法是专有的,需要保持安全。这排除了在 Java 中实现相同功能的可能性,因为 Java 太容易被反向编译了。事实上,我的前任竭尽全力(理所当然地)混淆了 C/C++ 源代码。这些库可以与 Shell、本机 C/C++ 二进制可执行文件(.exe 等)以及其他应用程序(其中调用来自(大部分)完全包含的应用程序)配合良好。该源提供了确保调用它的应用程序实际上是受信任的应用程序的方法(听起来类似于代码签名,但我可以向您保证它对这些源文件所做的事情要复杂得多)。

我正在尝试将此功能扩展到我们的企业 Java 架构中,为了做到这一点,我需要能够返回到调用的来源,即使这意味着只是访问已部署的 WAR 甚至是 EAR app 已打包,因此我可以将源文件与 C/C++ 源一起使用。因此,如果调用来自应用程序 A,并且应用程序部署在 App_A.EAR 中,我想获取该信息并调用 C/C++,追溯到该 EAR 并使用它。如果这听起来令人困惑,我深表歉意,但我(作为行为问题)遗漏了文件(.exe 或 JAR/WAR/EAR)的大部分用途。

再次感谢您提供的任何帮助!

* 编辑*

乍得

I have a need to interface with C/C++ from Java Enterprise applications. I would like to write a class that will be able to gather Node/Cell information, possibly any additional information about where the app is deployed, so I can, from C++, trace back to the JAR in the filesystem where the call came from (authoritatively). Is there a particular Java library that I could utilize that will give this kind of information about the application? Ideally, what would happen is: (lets call it EnvProvider)

  1. Java App calls EnvProvider
  2. EnvProvider gathers information about the Java application that invoked it
  3. EnvProvider calls wrapped C++ (CORBA, SOAP perhaps?) and passes this information
  4. C++ traces back up the filsystem to the calling app, to inspect the actual JAR files where purported application call came from.

It sounds trivial (outlined here in a mere 4 steps) but from my research thus far, it appears that there is no good way to get enough information about the Java Application FROM the Java Application itself. By "enough" information, I am talking about enough to give the C++ enough information to walk a filesystem and find a deployed EAR, JAR, WAR.

Any information that you could provide would be GREATLY appreciated!

Regards

Chad

* EDIT *

Kim, thank you for the response. Let me explain a bit why I need to get this particular trace.

I am working on/with a cryptographic library that is written in C/C++. They were written by my predecessor here (where I work) and they are very well tested. They provide more than just encryption, however, and the algorithms that are contained within are proprietary and need to remain secure. This rules out implementing the same in Java, as Java is too easily reverse-compiled. In fact, my predecessor went to great lengths (justifiably) to obfuscate the C/C++ source. These libraries work well with Shell, native C/C++ binary executables (.exe, etc.) as well as other applications where the call will come from a (mostly) wholly contained application. This source provides ways to ensure that the application calling it is in fact a trusted application (sounds similar to code signing, but I can assure you that what it does with these source files is far more complex).

I am trying to extend this functionality into our Enterprise Java architecture and in order to do so, I need to be able to get back to where the call came from, even if that means just getting to a deployed WAR or even the EAR that the app was packaged in, so I can use the source files with the C/C++ source. So if the call came from application A, and application was deployed in App_A.EAR, I would like to get that info and call out to the C/C++, trace back to that EAR and work with it. If that sounds confusing, I apologize, but I am (as a matter of conduct) leaving out a large part of what the files (.exe or JAR/WAR/EAR) are used for.

Thank you again for any assistance you could provide!

* EDIT *

Chad

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

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

发布评论

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

评论(1

巷子口的你 2024-10-26 01:06:57

在得到答案之前,您可能需要考虑三个问题:

  1. 为什么需要找到底层的 jar/ear/war/class 文件?您担心运行恶意代码吗?如果是这样,那么我强烈建议使用 代码签名安全性 策略。这些是平台内置的适当工具。
  2. 应用程序服务器以及企业应用程序可能使用自定义类加载器,这些加载器可以以其他应用程序无法立即访问的方式存储 jar 或类文件。我不记得任何这样的例子,但请记住,Java 不会强制或强制类加载器如何将资源映射到物理文件的任何一种方式,只要它们一致地执行即可。根据设计,用于加载类和资源的接口故意与底层操作系统的特性分离。特别是,如果 JAR 文件有助于加速和管理类加载器管理的资源,那么企业应用程序实现可能会有动力去扰乱 JAR 文件的存储方式。
  3. 对于集群环境,您可能不走运。 Java Enterprise Edition 规范并未规定或管理集群中不同节点之间通信的所有部分。特定供应商可能拥有专有接口,允许您确定远程接口正在与哪个节点通信,但由于集群和负载平衡的目标是使其对应用程序及其客户端透明,因此您可能更不可能访问此信息。

好吧,开始回答。您可能想尝试查看 Class.getProtectionDomainProtectionDomain.getCodeSource

ProtectionDomain protectionDomain = someObject.getClass().getProtectionDomain();
SourceLocation sourceLocation = protectionDomain.getCodeSource();
URL url = sourceLocation.getLocation();

请注意,调用 getProtectionDomain 可能会导致 SecurityException 取决于有效的安全策略。

更新:

听起来您的软件正在与作斗争安全和信任问题。但是您不必每次运行代码时都检查二进制代码。您可以通过代码签名获得相同级别的信任。如何? 签署代码。

  1. 当外部应用程序需要与您的库交互时,请索取二进制代码的副本以供检查。
  2. 当您对结果感到满意时,请使用您自己的私钥对代码进行签名。
  3. 接下来,设置一个安全策略,仅允许您签名的应用程序运行。

例如,使用 RSA 和 2048 位密钥,甚至更大的密钥大小,实际上不可能用当今已知的针对 RSA 的攻击来替换签名代码的任何部分。

此策略要求您控制应用程序服务器及其运行所在的 JVM。如果您的信任问题超出了这个范围,您可能需要开始考虑强制使用开源应用程序服务器,您可以在其中检查源代码并签署二进制文件,并最终检查 JVM 本身。

在不了解有关您的架构和设置的具体细节的情况下,我仍然建议利用 Java 平台内置的安全功能。

I have three concerns you might want to consider before I get to the answer:

  1. Why do you need to find the underlying jar/ear/war/class file? Are you worried about running malicious code? If so, then I strongly recommend using code signing and security policies instead. Those are the proper tools that come built-in with the platform.
  2. Application servers as well as enterprise applications might use custom class loaders that could store the jar or class files in a way that isn't immediately accessible to other applications. I can't remember any examples of such, but this bear in mind that Java does not impose or mandate any one way for how class loaders maps resources to physical files, as long as they do it consistently. By design, the interface for loading classes and resources is deliberately decoupled from the idiosyncrasies of the underlying operating system. Especially enterprise application implementations could have an incentive to mess with the way jar files are stored if it helps speed up and manage class loader managed resources.
  3. For clustered environments, you're probably out of luck. All the pieces that facilitate communication between the different nodes in a cluster are not prescribed nor governed by the Java Enterprise Edition specification. A particular vendor might have proprietary interfaces that allow you to determine which node a remote interface is talking to, but since the goal of clustering and load balancing is to make it transparent to the app and its clients, you're probably even less likely to get access to this information.

Okay, on to the answer. You might want to try looking into Class.getProtectionDomain and ProtectionDomain.getCodeSource:

ProtectionDomain protectionDomain = someObject.getClass().getProtectionDomain();
SourceLocation sourceLocation = protectionDomain.getCodeSource();
URL url = sourceLocation.getLocation();

Beware that calling getProtectionDomain might cause a SecurityException depending on the security policy in effect.

Update:

It sounds like your software is struggling with security and trust issues. But you don't have to inspect the binary code each and every time you run the code. You can achieve the same level of trust with code signing. How? You sign the code.

  1. When an external application needs to interact with your library, ask for a copy of the binary code for inspection.
  2. When you're satisfied with the result, sign the code using your own private key.
  3. Next, set up a security policy that will only allow applications signed by you to run.

With e.g. RSA and a 2048 bit key, or even larger key sizes, it is practically impossible to substitute any part of the signed code with today's known attacks against RSA.

This strategy require that you control the application server and the JVM on which it is running. If your trust issues go beyond this, you probably need to start thinking about mandating an open source application server, where you can inspect the source code and sign the binaries, and, ultimately, the JVM itself.

Without knowing specific details about your architecture and setup, I will still recommend leveraging the security features built into the Java platform.

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