OSGi服务平台核心规范 Release 4.3

需积分: 9 11 浏览量更新于2024-07-31 收藏 3.35MB PDF 举报

"OSGi规范，全称为Open Service Gateway Initiative，是一种Java平台上的模块化系统和服务平台标准。这个规范由OSGi Alliance发布，主要目的是为了实现动态、可扩展且模块化的软件系统。Release 4, Version 4.3是该规范的一个版本，发布于2011年4月。它提供了关于OSGi服务平台的核心规范，涵盖了一系列的接口和框架，以支持在Java应用程序中进行组件化开发和动态服务发现与依赖管理。 OSGi的核心概念包括以下几个方面： 1. **模块化**：OSGi引入了一种名为`Bundle`的模块化机制，每个Bundle都是一个独立的代码单元，包含类、资源和元数据。Bundle之间通过导出和导入包来声明依赖关系，实现了模块间的隔离和互操作性。 2. **生命周期管理**：Bundle有自己的生命周期，包括安装、启动、暂停、更新和卸载等状态。开发者可以通过控制Bundle的状态来实现系统的动态更新和配置。 3. **服务注册与发现**：OSGi提供了一个服务注册表，允许Bundle发布和查找服务。这种机制使得组件之间可以通过服务接口进行通信，而不是直接引用对方，从而降低了耦合度。 4. **动态性**：OSGi允许在运行时动态地添加、移除和修改服务和Bundle，这使得系统能够根据需求和环境的变化自我调整。 5. **安全**：OSGi提供了细粒度的安全模型，允许控制Bundle的访问权限，确保了组件之间的安全交互。 6. **版本管理**：OSGi对包版本进行了有效的管理，使得不同版本的包可以共存，并解决了版本冲突问题。 7. **框架**：OSGi规范定义了一个基础框架，这个框架提供了上述功能的基础，使得开发者可以构建符合规范的应用程序。在实现OSGi规范时，开发者需要注意遵守其规定，如不修改、扩展OSGi名称空间，不创建与之相关的派生工作。此外，OSGi Alliance提供的许可协议允许查看、下载和复制规格文档，以及创建和分发实现该规格的软件，但需遵循一定的授权条件，如非排他性、无转授权等。通过使用OSGi规范，开发者能够在Java环境中构建更灵活、可维护的大型软件系统，减少因系统复杂性增加而带来的维护困难。它被广泛应用于嵌入式系统、企业应用服务器、设备管理和物联网解决方案等领域。"

References Introduction

Page 10 OSGi Service Platform Release 4, Version 4.3

OSGi Service Platform Release 4, Version 4.3 Page 11

Security Layer Version 1.6 Introduction

2Security Layer

Version 1.6

2.1 Introduction

The OSGi Security Layer is an optional layer that underlies the OSGi Service Platform. The layer is

based on the Java 2 security architecture. It provides the infrastructure to deploy and manage applica-

tions that must run in fine-grained controlled environments.

2.1.1 Essentials

• Fine-grained – The control of applications running in an OSGi Framework must allow for detailed

control of those applications.

• Manageable – The security layer itself does not define an API to control the applications. The man-

agement of the security layer is left to the life cycle layer.

• Optional – The security layer is optional.

2.2 Security Overview

The Framework security model is based on the Java 2 specification. If security checks are performed,

they must be done according to [3] Java 2 Security Architecture. It is assumed that the reader is familiar

with this specification. The security layer is optional, see Optional Security on page 11.

2.2.1 Code Authentication

The OSGi Service Platform can authenticate code in the following ways:

•By location

•By signer

At higher layers there are defined services that can manage the permissions that are associated with

the authenticated unit of code. These services are:

• Permission Admin service – Manages the permission based on full location strings.

• Conditional Permission Admin service – Manages the permissions based on a comprehensive condi-

tional model, where the conditions can test for location or signer.

For signing, this requires the JAR files to be signed; this is described in Digitally Signed JAR Files on

page 12.

2.2.2 Optional Security

The Java platform on which the Framework runs must provide the Java Security APIs necessary for

Java 2 permissions. On resource-constrained platforms, these Java Security APIs may be stubs that

allow the bundle classes to be loaded and executed, but the stubs never actually perform the security

checks. The behavior of these stubs must be as follows:

• checkPermission – Return without throwing a SecurityException.

• checkGuard – Return without throwing a SecurityException.

• implies – Return true.

This behavior allows code to run as if all bundles have AllPermission.

Digitally Signed JAR Files Security Layer Version 1.6

Page 12 OSGi Service Platform Release 4, Version 4.3

2.3 Digitally Signed JAR Files

This section defines in detail how JAR files must be signed. This section therefore overlaps with the

different JAR file specifications that are part of the different versions of Java. The reason for this

duplication is that there are many aspects left as optional or not well-defined in these specifications.

A reference was therefore insufficient.

Digitally signing is a security feature that verifies the following:

• Authenticates the signer

• Ensures that the content has not been modified after it was signed by the principal.

In an OSGi Framework, the principals that signed a JAR become associated with that JAR. This associ-

ation is then used to:

• Grant permissions to a JAR based on the authenticated principal

• Target a set of bundles by principal for a permission to operate on or with those bundles

For example, an Operator can grant the ACME company the right to use networking on their devices.

The ACME company can then use networking in every bundle they digitally sign and deploy on the

Operator’s device. Also, a specific bundle can be granted permission to only manage the life cycle of

bundles that are signed by the ACME company.

Signing provides a powerful delegation model. It allows an Operator to grant a restricted set of per-

missions to a company, after which the company can create JARs that can use those permissions,

without requiring any intervention of, or communication with, the Operator for each particular JAR.

This delegation model is shown graphically in Figure 2.1.

Figure 2.1 Delegation model

Digital signing is based on public key cryptography. Public key cryptography uses a system where there

are two mathematically related keys: a public and a private key. The public key is shared with the

world and can be dispersed freely, usually in the form of a certificate. The private key must be kept a

secret.

Messages signed with the private key can only be verified correctly with the public key. This can be

used to authenticate the signer of a message (assuming the public key is trusted, this is discussed in

Certificates on page 15).

The digital signing process used is based on Java 2 JAR signing. The process of signing is repeated,

restricted and augmented here to improve the inter-operability of OSGi bundles.

2.3.1 JAR Structure and Manifest

A JAR can be signed by multiple signers. Each signer must store two resources in the JAR file. These

resources are:

• A signature instruction resource that has a similar format like the Manifest. It must have a .SF

extension. This file provides digests for the complete manifest file.

Developer

Operator

Enterprise

OSGi

Service

Platform

Employee

grantsuses

provides

installs

permissions

OSGi Service Platform Release 4, Version 4.3 Page 13

Security Layer Version 1.6 Digitally Signed JAR Files

• A PKCS#7 resource that contains the digital signature of the signature instruction resource. See

[11] Public Key Cryptography Standard #7 for information about its format.

These JAR file signing resources must be placed in the META-INF directory. For signing, the META-

INF directory is special because files in there are not signed in the normal way. These signing

resources must come directly after the MANIFEST.MF file, and before any other resources in a JAR

stream. If this is not the case, then a Framework should not accept the signatures and must treat the

bundle as unsigned. This ordering is important because it allows the receiver of the JAR file to stream

the contents without buffering. All the security information is available before any resources are

loaded. This model is shown in Figure 2.2.

Figure 2.2 Signer files in JAR

The signature instruction resource contains digests of the Manifest resource, not the actual resource

data itself. A digest is a one way function that computes a value from the bytes of a resource in such a

way that it is very difficult to create a set of bytes that matches that digest value.

The JAR Manifest must therefore contain one or more digests of the actual resources. These digests

must be placed in their name section of the manifest. The name of the digest header is constructed

with its algorithm followed by -Digest. An example is the SHA1-Digest. It is recommended that

OSGi Framework implementations support the following digest algorithms.

• MD5 – Message Digest 5, an improved version of MD4. It generates a 128-bit hash. It is described at

page 436 in [7] RFC 1321 The MD5 Message-Digest Algorithm.

• SHA1 – An improved version of SHA, delivers a 160 bit hash. It is defined in [6] Secure Hash Algo-

rithm 1.

The hash must be encoded with a Base 64 encoding. Base 64 encoding is defined in [8] RFC 1421 Pri-

vacy Enhancement for Internet Electronic Mail.

For example, a manifest could look like:

Manifest-Version: 1.0

Bundle-Name: DisplayManifest

↵

Name: x/A.class

SHA1-Digest: RJpDp+igoJ1kxs8CSFeDtMbMq78=

↵

Name: x/B.class

SHA1-Digest: 3EuIPcx414w2QfFSXSZEBfLgKYA=

↵

Graphically this looks like Figure 2.3.

META-INF/

MANIFEST.MF

ACME.SF

ACME.RSA

DAFFY.SF

DAFFY.DSA

... other files

Digitally Signed JAR Files Security Layer Version 1.6

Page 14 OSGi Service Platform Release 4, Version 4.3

Figure 2.3 Signer files in JAR

OSGi JARs must be signed by one or more signers that sign all resources except the ones in the META-

INF directory; the default behavior of the jarsigner tool. This is a restriction with respect to standard

Java JAR signing; there is no partial signing for an OSGi JAR. The OSGi specification only supports

fully signed bundles. The reason for this restriction is because partially signing can break the protec-

tion of private packages. It also simplifies the security API because all code of a bundle is using the

same protection domain.

Signature files in nested JAR files (For example JARs on the Bundle-ClassPath) must be ignored.

These nested JAR files must share the same protection domain as their containing bundle. They must

be treated as if their resources were stored directly in the outer JAR.

Each signature is based on two resources. The first file is the signature instruction file; this file must

have a file name with an extension .SF. A signature file has the same syntax as the manifest, except

that it starts with Signature-Version: 1.0 instead of Manifest-Version: 1.0.

The only relevant part of the signature resource is the digest of the Manifest resource. The name of

the header must be the name algorithm (e.g. SHA1) followed by -Digest-Manifest. For example:

Signature-Version: 1.0

SHA1-Digest-Manifest: RJpDp+igoJ1kxs8CSFeDtMbMq78=

MD5-Digest-Manifest: IIsI6HranRNHMY27SK8M5qMunR4=

The signature resource can contain name sections as well. However, these name sections should be

ignored.

If there are multiple signers, then their signature instruction resources can be identical if they use the

same digest algorithms. However, each signer must still have its own signature instruction file. That

is, it is not allowed to share the signature resource between signers.

The indirection of the signature instruction files digests is depicted in Figure 2.4 for two signers:

ACME and DAFFY.

Figure 2.4 Manifest, signature instruction files and digests in JAR

META-INF/

MANIFEST.MF

... other files

Manifest-Version: 1.0

Name: x/A.class

SHA1-Digest:

RJpDp+igoJ1k...

Name: x/B.class

SHA1-Digest:

3EuIPcx414w2...

x/A.class

x/B.class

META-INF/

MANIFEST.MF

... other files

ACME.SF

DAFFY.SF

Digest functions

Manifest entry

certificates

signature

with private key

certificates

signature

with private key

ACME.RSA

DAFFY.DSA

Resource

剩余357页未读，继续阅读

weimingdong123

粉丝: 0
资源: 20

OSGi服务平台核心规范 Release 4.3

osgi最新规范第四版

OSGi规范（r4）中文版

osgi.r4.services

OSGI+Specification+r4.core

osgi规范_R4_zh.pdf

OSGI_R4v42.javadoc.zip

OSGI-R4 规范-中文

OSGI r4规范

OSGi R4规范,中文版

OSGI R4规范，学习必读手册

最新资源