在上一篇文章中 ，我们介绍了为Java应用程序实现沙箱的方法，在其中我们可以安全地运行移动代码 。

这篇文章探讨了如何在OSGi环境中执行相同的操作。

OSGi

OSGi规范 为Java定义了一个动态模块系统 。 因此，它是实施那种可以使您的应用程序动态添加移动代码的插件系统的理想选择。

OSGi中的安全性基于我们之前讨论的Java 2安全性体系结构，因此您可以重复使用有关代码签名等方面的知识。

但是，OSGi进一步走了几步。

吊销权限

Java权限模型的弱点之一是，您只能显式授予权限，而不能撤销它们。 在许多情况下，您都希望允许所有内容（特殊情况除外）。

没有使用标准Java权限来执行此操作的方法，但是幸运的是，OSGi引入了一种解决方案。

缺点是OSGi引入了自己的语法来指定策略。

以下示例显示如何拒绝com.acme.secret子包的PackagePermission ：

DENY {( ..PackagePermission "com.acme.secret.*" "import,exportonly" )
} "denyExample"

（在下面的示例中，我给出了权限类的简单名称，而不是完全限定名称。我通过在简单名称前面加上..暗示这一点.. ）

PackagePermission是OSGi定义的用于对包导入和导出进行授权的权限。 您的应用程序可以使用这样的策略来确保移动代码无法调用给定程序包中的类，例如，以限制对数据库的直接访问。

权限的可扩展条件

OSGi带来的第二个改进是，可以在运行时动态评估授予权限的条件。

以下示例显示如何有条件地授予ServicePermission ：

ALLOW {[ ..BundleSignerCondition "* ; o=ACME" ]( ..ServicePermission "..ManagedService" "register" )
} "conditionalExample"

ServicePermission是OSGi定义的权限，用于限制对OSGi服务的访问。

条件是方括号之间的部分。 OSGi定义了两个条件，它们对应于常规Java策略中的signedBy和codeBase构造。

您还可以定义自己的条件 。 该规范给出了有关实施条件的详细说明，尤其是有关性能的说明。

不同类型的权限

OSGi带给Java权限模型的最后一项创新是存在不同类型的权限。

捆绑包可以指定自己的权限。 这并不意味着捆绑包可以为其授予权限，而是可以指定其运行所需的最大特权。 这些权限称为本地权限 。

OSGi框架确保该捆绑包永远不会拥有比本地权限更多的权限，从而实现了最小特权的原则 。

实际上，该说法并不完全准确。 每个捆绑软件都将具有在OSGi环境中运行所需的某些权限，例如能够读取org.osgi.framework.*系统属性。

这些权限被称为隐式权限 ，因为每个捆绑软件都将拥有它们，无论权限是否明确授予捆绑软件。

权限的最终类型是系统权限 。 这些是授予捆绑软件的权限。

有效权限是在运行时检查的一组权限：

effective = (local ∩ system) ∪ implicit

本地权限启用审核。 在将捆绑软件安装到OSGi环境之前，您可以检查OSGI-INF/permissions.perm的捆绑软件许可资源 ，以查看捆绑软件需要哪些许可。

如果您不满意向捆绑软件授予这些权限，则可以决定不安装捆绑软件。 关键是您无需运行捆绑软件，也无需访问其源代码就可以了解所有这些信息。

集成到Java权限模型中

OSGi框架通过子类化ProtectionDomain将其扩展的权限模型集成到标准Java权限模型中。

每个捆绑软件都为此目的获得一个BundleProtectionDomainImpl 。

这种方法使OSGi可以利用您已经了解的标准Java权限模型，因此您可以重用该领域的大多数技能。 您唯一需要重新学习的就是如何编写策略。

权限模型比较

为了使OSGi权限模型更有效，请考虑以下比较表，该表使用了XACML规范中的术语：

权限模型	标准Java	OSGi
特效	允许	允许，拒绝
目标条件	codeBase，已签名	codeBase，signedBy，自定义条件
组合算法	先申请	首先适用，本地/系统/隐式

从该表中，您可以看到OSGi模型比标准Java权限模型更具表现力，尽管不如XACML表现力强。

参考： 安全软件开发博客上来自我们JCG合作伙伴 Remon Sinnema的OSGi许可 。

翻译自: https://www.javacodegeeks.com/2012/11/permissions-in-osgi.html