Java 如何在ApacheSling中的OSGI服务调用中识别用户的身份？

在ApacheSling中：如果您有一个多租户设置或环境，用户可以在其中部署自己的代码（例如JSP或实际的Java/Groovy代码或诸如此类的代码）：是否有一种方法可以确定从被调用的OSGI服务中发送当前请求的用户的身份？它必须能够安全地抵御恶意代码

背景：通常情况下，依靠网络来保护用户不应该看到的东西就足够了。但是，有时您希望OSGI服务使用访问服务实现所需的JCR资源的内部内容，但您不希望用户能够访问这些资源。在这里，您可能有某种防篡改的方法来识别用户，以便检查其对服务的权限

有些事情显然不起作用

• 您可以将users ResourceResolver作为参数传递给OSGI服务中的调用，并检查ResourceResolver.getUserId（）返回的内容。通过传入一个包装器，可以很容易地破坏这一点，该包装器委托给原始ResourceResolver，但在这里为getUserId（）返回一些任意内容
• 可以将users ResourceResolver作为参数传递给服务，检查用户对资源树中某个路径的访问，并设置JCR权限以保护该路径。不幸的是，这并不像听起来那么容易：恶意代码可能再次通过一个包装器，该包装器返回此路径的模拟资源，模拟访问。我认为这唯一可行的方法是，用户必须对该路径进行写访问，服务用户用于检查该路径是否被实际修改。但由于性能和其他原因，这不是一个好方法

你有没有其他可行的想法？非常感谢

---

注意：我知道这里还有其他攻击您必须阻止（例如，但我想至少让它变得不重要。

它是一个多租户系统，因此每个用户都会属于某个租户。根据租户上下文，您可以使用RequestContext对象，它实际检查该租户的用户是否有权访问SecurityManager，并允许特定用户使用。

我发现至少有一件事：返回请求为其自身进行身份验证的最后一个ResourceResolver。因此，如果将ResourceResolver Factory注入到服务中，则此返回的ResourceResolver的getUserId似乎至少提供了用户可以模拟的用户id

（请注意，这不一定是用户本身的原始id，因为如果使用了代码，则会更改结果。但这至少意味着用户可以模拟返回的用户id。）

另一种方法是使用类似Composum的ServletFilter，它将原始SlingHttpRequest使用的ResourceResolver保存在ThreadLocal中（如果恶意代码能够部署优先级更高的ServletFilter，那么该方案就会失效，但我们必须在某个地方停止）

---

不幸的是，这两种想法都不适用于服务解析器，因为ResourceResolverFactory.getServiceResolver不设置esourceResolverFactory.getThreadResourceResolver。

谢谢，但请您详细说明一下，我如何从OSGI服务内部找到租户上下文？毕竟，它不能作为参数传递，不能作为参数传递可以被恶意代码任意设置。我也没有在任何Sling库中找到RequestContext类。