4.3版OSGi规范详解：入门指南与Java基础知识

5星 · 超过95%的资源需积分: 6 11 浏览量更新于2024-07-18 收藏 3.35MB PDF 举报

OSGi规范4.3.0是The OSGi Alliance于2011年发布的第四版核心规范，它对于想要深入理解OSGi（开放服务网关接口）概念的初学者来说是一个重要的学习资料。然而，由于其技术深度，建议读者具备一定的Java基础，以便更好地理解和应用这些概念。 OSGiServicePlatform是该规范的核心部分，它定义了一个服务提供与消费的平台架构，允许组件间的动态互操作和服务发现。在OSGi的生态系统中，这个平台扮演着连接不同模块并实现松耦合服务交互的关键角色。 CoreSpecification详细规定了OSGi框架如何组织和管理服务、组件、生命周期管理以及命名空间等核心要素。它包括服务注册与查找机制，如服务提供者接口（SPI）的定义和依赖注入（DI）的实现，确保组件之间的透明通信。版权方面，根据OSGi Specification License 1.0，The OSGi Alliance授予用户查看、下载和复制规范的权利，但明确禁止创建规范的衍生作品。此外，用户还被授权在遵守特定条件的情况下，创建和分发符合规范的实现，包括完全实现所有所需接口和功能，且不得修改或扩展OSGi命名空间，也不包含任何公共或受保护的元素。在4.3.0版本中，可能还包含了对新功能的支持，如更高级的模块化设计、安全性增强、性能优化以及对云计算和物联网等新兴技术的兼容性改进。同时，该规范可能会强调服务的生命周期管理和依赖管理，以促进高效、稳定和可维护的软件架构。学习OSGi规范4.3.0不仅有助于开发者理解如何构建模块化、可重用的Java应用程序，还能提升他们构建可扩展和灵活系统的能力。通过遵循这一规范，开发者可以充分利用OSGi的优势，构建出能够适应不断变化需求的应用环境。

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页未读，继续阅读

zhuguiqian

粉丝: 10
资源: 4

4.3版OSGi规范详解：入门指南与Java基础知识

OSGI规范中文版

osgi规范r4..

osgi.core-4.3.0

spring osgi 规范 中文版

osgi规范实战进阶等等等

OSGI规范（中文版）

OSGi规范（r4）中文版

docs:OSGi 规范项目文档网站。 规范、Javadoc 等

osgi规范_R4_zh.pdf

cpp-ApacheCelix是一个使用C和C实现的OSGi规范的项目

最新资源

spring osgi 规范中文版

docs:OSGi 规范项目文档网站。规范、Javadoc 等