在上一篇文章中 ，我們介紹了為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