CN103034789A

CN103034789A - 一种组件部署方法、装置及安全框架

Info

Publication number: CN103034789A
Application number: CN2012105295518A
Authority: CN
Inventors: 盛凌艳; 罗俭; 陈乐春; 罗端红; 刘民; 温尚卓
Original assignee: CVIC Software Engineering Co Ltd
Current assignee: CVIC Software Engineering Co Ltd
Priority date: 2012-12-10
Filing date: 2012-12-10
Publication date: 2013-04-10
Anticipated expiration: 2032-12-10
Also published as: CN103034789B

Abstract

本申请公开了一种组件部署方法、装置及安全框架，所述方法包括获取组件部署请求，所述组件部署请求包括组件标识信息；若预设的部署规则成立，提取所述组件部署请求中包含的签名证书信息；其中，所述签名证书信息包括第一证书列表，所述第一证书列表包括至少一条证书信息；获取OSGi框架配置文件中的第二证书列表；标记所述第一证书列表中与所述第一证书列表中相同的证书信息；将所述第一证书列表中被标记的证书信息作为有效证书信息；若所述有效证书信息满足预设签名规则，将与所述组件标识信息相对应的组件置入所述OSGi框架中。本申请实施例通过对组件的签名进行认证实现安全部署，在保证组件安全部署的前提下，明显提高组件部署的效率。

Description

一种组件部署方法、装置及安全框架

技术领域

本申请涉及OSGi规范技术领域，特别涉及一种组件部署方法、装置及安全框架。

背景技术

OSGi(Open Service Gateway initiative)技术是面向Java的动态模型系统。OSGi服务平台向Java提供服务，这些服务使Java成为软件集成和软件开发的首选环境。OSGi技术规范的核心组件是OSGi框架，该OS Gi框架为应用程序即组件（简称Bundle）提供了一个标准环境，使得组件供应商提供的组件能够部署在OSGi框架中，由用户调用并执行为用户提供服务，同时对用户请求访问或使用组件资源的各种权限检查提供支持。

组件能否被部署到OSGi框架中，取决于组件供应商。目前一般采用人工辨认的方案来实现对不同组件供应商提供的组件进行部署，由此组件部署速度较慢，部署效率较低。随着组件供应商的数量越来越多，且，每个组件供应商提供的组件越来越多，OSGi框架所面对的组件部署需求也越来越多，由此亟需一种针对组件供应商的不同，对其所需部署的组件做出不同的部署方案的组件安全部署方案。

发明内容

有鉴于此，本申请的目的是提供一种组件部署方法、装置及安全框架，用以解决现有技术中由于组件供应商不同，无法对其所提供的组件做出不同的部署方案，导致组件部署效率较低的技术问题。

本申请提供了一种组件部署方法，所述方法包括：

获取组件部署请求，所述组件部署请求包括组件标识信息；

若预设的部署规则成立，提取所述组件部署请求中包含的签名证书信息；

其中，所述签名证书信息包括第一证书列表，所述第一证书列表包括至少一条证书信息；

获取OSGi框架配置文件中的第二证书列表；

标记所述第一证书列表中与所述第二证书列表中相同的证书信息；

将所述第一证书列表中被标记的证书信息作为有效证书信息；

若所述有效证书信息满足预设签名规则，将与所述组件标识信息相对应的组件置入所述OSGi框架中。

上述方法，优选的：

所述预设签名规则为所述有效证书信息的有效公钥信息与所述第二证书列表的有效公钥信息相同，且所述有效证书信息的签名主体与所述第二证书列表中的签名主体相同；

若所述有效证书信息不满足预设签名规则，所述方法还包括：

结束当前组件部署。

上述方法，优选的：

所述预设的部署规则为所述组件部署请求表明需要对与所述组件标识信息相对应的组件进行安全部署；

若所述预设的部署规则不成立，所述方法还包括：

执行所述将与所述组件标识信息相对应的组件置入所述OSGi框架中。

上述方法，优选的，预先依据所述OSGi框架配置文件中组件供应商的配置信息，生成所述OSGi框架的组件资源的权限表；

其中，所述权限表包括至少一条权限值，所述权限值表明所述组件供应商提供的组件对所述OSGi框架中所有组件资源进行访问的权限；

在所述将与所述组件标识信息相对应的组件置入所述OSGi框架中之后，所述方法还包括：

获取组件的资源访问请求信息，所述资源访问请求信息包括组件地址信息及访问资源信息；

若在所述权限表中查询到与所述组件地址信息相对应的组件供应商的权限值，依据查询到的权限值生成第一授权信息，所述第一授权信息表明允许与所述资源访问请求信息相对应的访问者以查询到的权限值对与所述访问资源信息相对应的组件资源进行访问。

上述方法，优选的，若在所述权限表中未查询到与所述组件地址信息相对应的组件所属组件供应商的权限值，所述方法还包括：

获取与所述组件地址信息相对应的组件供应商的证书信息；

依据获取的证书信息，计算与所述资源访问请求信息相对应的访问者,对与所述待访问资源信息相对应的组件资源进行访问的权限值；

依据计算的权限值生成第二授权信息，所述第二授权信息表明允许与所述资源访问请求信息相对应的访问者以计算得到的权限值,对与所述访问资源信息相对应的组件资源进行访问。

本申请还提供了一种组件部署装置，所述装置包括：

请求获取单元，用于获取组件部署请求，所述组件部署请求包括组件标识信息；

证书提取单元，用于若预设的部署规则成立，提取所述组件部署请求中包含的签名证书信息；

证书获取单元，用于获取OSGi框架配置文件中的第二证书列表；

签名认证单元，用于标记所述第一证书列表中与所述第二证书列表中相同的证书信息，将所述第一证书列表中被标记的证书信息作为有效证书信息；

逻辑判断单元，用于判断所述有效证书信息是否满足预设签名规则，如果是，触发组件部署单元；

所述组件部署单元，用于将与所述组件标识信息相对应的组件置入所述OSGi框架中。

上述装置，优选的：

若所述有效证书信息不满足预设签名规则，所述逻辑判断单元还用于结束当前组件部署。

上述装置，优选的：

所述证书提取单元，还用于若所述预设的部署规则不成立，触发所述组件部署单元。

上述装置，优选的，所述装置还包括：

权限表生成单元，用于预先依据所述OSGi框架配置文件中组件供应商的配置信息，生成所述OSGi框架的组件资源的权限表；

访问信息获取单元，用于获取组件的资源访问请求信息，所述资源访问请求信息包括组件地址信息及访问资源信息；

权限值查询单元，用于在所述权限表中查询与所述组件地址信息相对应的组件供应商的权限值，若查找到，触发第一信息生成单元；

所述第一信息生成单元，用于依据查询到的权限值生成第一授权信息，所述第一授权信息表明允许与所述资源访问请求信息相对应的访问者以查询到的权限值对与所述访问资源信息相对应的组件资源进行访问。

本申请还提供了一种安全框架，其特征在于，包括如上述任意一项所述的组件部署装置。

由上述方案可知，本申请提的一种组件部署方法、装置及安全框架，在获取组件部署请求之后，若预设的部署规则成立，提取所述组件部署请求中包含的签名证书信息，获取OSGi框架配置文件中的第二证书列表，标记所述第一证书列表中与所述第一证书列表中相同的证书信息，将所述第一证书列表中被标记的证书信息作为有效证书信息，若所述有效证书信息满足预设签名规则，将与所述组件标识信息相对应的组件置入所述OSGi框架中，由此实现组件的安全部署，相对于现有技术中的组件部署方案，通过对组件的签名进行认证实现安全部署，既而在保证组件安全部署的前提下，明显提高了组件部署的效率。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请提供的一种组件部署方法实施例一的流程图；

图2为本申请提供的一种组件部署方法实施例一的另一流程图；

图3为本申请提供的一种组件部署方法实施例一的又一流程图；

图4为本申请提供的一种组件部署方法实施例二的部分流程图；

图5为本申请提供的一种组件部署方法实施例二的另一部分流程图；

图6为本申请提供的一种组件部署装置实施例三的结构示意图；

图7为本申请提供的一种组件部署装置实施例三的另一结构示意图；

图8为本申请提供的一种组件部署装置实施例四的结构示意图；

图9为本申请提供的一种组件部署装置实施例四的另一结构示意图；

图10为本申请提供的一种安全框架实施例五的示例图；

图11为本申请提供的安全框架实施例五对Bundle签名认证的时序图；

图12为本申请提供的安全框架实施例五对Bundle的权限管理流程图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

参考图1，其示出了本申请提供的一种组件部署方法实施例一的流程图，所述方法可以包括以下步骤：

步骤101：获取组件部署请求，所述组件部署请求包括组件标识信息。

其中，所述组件部署请求为用户根据其需要安装于OSGi框架的组件生成，该组件部署请求中包括组件标识信息，表明待安装（部署）组件的身份信息。

步骤102：判断预设的部署规则是否成立，如果是，执行步骤103。

需要说明的是，所述预设的部署规则可以为空，即为：所述预设的部署规则成立，直接执行所述步骤103。

步骤103：提取所述组件部署请求中包含的签名证书信息。

其中，所述签名证书信息包括第一证书列表，所述第一证书列表包括至少一条证书信息。

步骤104：获取OSGi框架配置文件中的第二证书列表。

需要说明的是，本申请实施例采用的开放式部署通道，是基于签名机制的，即：OSGi框架将一系列的可信证书（根据具体实现而不同）、组件供应商的身份标识信息、签名主体、被签名组件资源文件、被签名组件的操作者以及操作者一系列的权限进行关联，并将这些关联信息置入OSGi框架的配置文件（或附属文件，如*.keystore文件）中，使得框架可以使用一种不可信的部署通道实现安全部署。

步骤105：标记所述第一证书列表中与所述第二证书列表中相同的证书信息。

需要说明的是，所述步骤105可以理解为：所述第二证书列表中至少包括一条证书信息与所述第一证书列表中的某一证书信息相同，将所述第一证书列表中相同的证书信息进行标记。

优选的，若所述第二证书列表中没有证书信息与所述第一证书列表中的证书信息相同，则说明与上述组件标识信息相对应的组件并非合法组件，不能置入所述OSGi框架中，所述方法还包括：

结束当前组件部署。

步骤106：将所述第一证书列表中被标记的证书信息作为有效证书信息。

其中，所述步骤106既完成对组件的签名认证，说明与所述组件标识信息相对应的组件供应商为所述OSGi框架的合法组件供应商，其提供的与所述组件标识信息相对应的组件可以安装至所述OSGi框架中。

步骤107：判断所述有效证书信息是否满足预设签名规则，如果是，执行步骤108。

需要说明的是，所述预设签名规则可为空，即默认所述预设签名规则成立，直接执行所述步骤108。

而所述有效证书信息表明与所述有效证书信息相对应的证书的签名日期在预设的有效期内，且不在预设的第三证书列表中，所述第三证书列表包括至少一条已经被撤销的证书信息。

步骤108：将与所述组件标识信息相对应的组件置入所述OSGi框架中。

例如，操作者（组件供应商）可以通过因特网或CD、PC等来提供组件（应用）。当用户从一个不可信的网站下载了一个应用之后，安全框架对签名信息进行校验。只有当签名是可信的（或者对不可信Bundle具有默认权限）时，框架才会安装这个应用。

优选的，签名机制提供签名、篡改检测机制和确认签名者（principal）即签名认证。

其中，Bundle通过签名，关联一系列的可信证书来提供组件提供商的身份证明，其中由于允许组件供应商授予证书与证书被授予其他提供商，证书之间存在该关联继而形成证书链。优选的，上述签名方式包括数字签名，其中，数字签名是指附加在数据单元上的一些数据，或是对数据单元所作的密码变换。如借助java keytool工具，Bundle通过数字签名命令根据keytool工具生成的信任库将该信任库设置的证书信息、密钥信息等部分信息选择对应的签名算法以数据字符的形式写入组件的附加文件，完成组件的数字签名。

而篡改检测机制实际篡改的是组件的数字签名。OSGi签名规则在JAR文件的数字签名一节中已经定义。数字签名算法可以检测到对JAR文件的修改以及对签名者验证信息的修改。因此，框架必需拒绝运行签名不匹配或者是签名者不可识别的组件。

由上述方案可知，本申请提的一种组件部署方法实施例一，在获取组件部署请求之后，若预设的部署规则成立，提取所述组件部署请求中包含的签名证书信息，获取OSGi框架配置文件中的第二证书列表，标记所述第一证书列表中与所述第一证书列表中相同的证书信息，将所述第一证书列表中被标记的证书信息作为有效证书信息，若所述有效证书信息满足预设签名规则，将与所述组件标识信息相对应的组件置入所述OSGi框架中，由此实现组件的安全部署，相对于现有技术中的组件部署方案，通过对组件的签名进行认证实现安全部署，既而在保证组件安全部署的前提下，明显提高了组件部署的效率。

优选的，参考图2，其示出了本申请提供的一种组件部署方法实施例一的另一流程图，所述预设签名规则为所述有效证书信息的有效公钥信息与所述第二证书列表的有效公钥信息相同，且所述有效证书信息的签名主体与所述第二证书列表中的签名主体相同；

其中，所述步骤107中，若所述有效证书信息不满足预设签名规则，所述方法还包括：

步骤S109：结束当前组件部署。

需要说明的是，在如图2所示的本申请实施例中，所述预设签名规则不为空，即所述步骤107具体为：

若所述有效证书信息的有效公钥信息与所述第二证书列表的有效公钥信息不同，或所述有效证书信息的签名主体与所述第二证书列表的签名主体不同，即可执行所述步骤S109结束当前组件部署。

优选的，参考图3，其示出了本申请提供的一种组件部署方法实施例一的又一流程图，所述预设的部署规则为所述组件部署请求表明需要对与所述组件标识信息相对应的组件进行安全部署；

其中，所述步骤102中，若所述预设的部署规则不成立，所述方法还包括：

执行所述步骤108将与所述组件标识信息相对应的组件置入所述OSGi框架中。

需要说明的是，在如图3所示的本申请实施例中，所述预设的部署规则不为空，即所述步骤107具体为：

若所述组件部署请求未表明需要对与所述组件标识信息相对应的组件进行安全部署，即可执行所述步骤108将与所述组件标识信息相对应的组件置入所述OSGi框架中。

参考图4，其示出了本申请提供的一种组件部署方法实施例二的部分流程图，预先依据所述OSGi框架配置文件中组件供应商的配置信息，生成所述OSGi框架的组件资源的权限表；

在所述步骤108之后，所述方法还可以包括以下步骤：

步骤401：获取组件的资源访问请求信息，所述资源访问请求信息包括组件地址信息及访问资源信息；

步骤402：在所述权限表中查询与所述组件地址信息相对应的组件供应商的权限值，若查询到，执行步骤403；

步骤403：依据查询到的权限值生成第一授权信息，所述第一授权信息表明允许与所述资源访问请求信息相对应的访问者以查询到的权限值对与所述访问资源信息相对应的组件资源进行访问。

由上述方案可知，本申请提的一种组件部署方法实施例二，在获取组件部署请求之后，若预设的部署规则成立，提取所述组件部署请求中包含的签名证书信息，获取OSGi框架配置文件中的第二证书列表，标记所述第一证书列表中与所述第一证书列表中相同的证书信息，将所述第一证书列表中被标记的证书信息作为有效证书信息，若所述有效证书信息满足预设签名规则，将与所述组件标识信息相对应的组件置入所述OSGi框架中，由此实现组件的安全部署，进一步的，在组件完成安全部署之后，对该组件访问资源文件的权限进行验证，相对于现有技术中的组件部署方案，通过对组件的签名进行认证实现安全部署，同时通过对组件的权限进行验证保证资源文件的安全，既而在保证组件安全部署的前提下，明显提高组件部署的效率的同时，提高OSGi框架资源文件的安全性。

优选的，参考图5，其示出了本申请实施例二的另一部分流程图，其中，在所述步骤402中，若在所述权限表中未查询到与所述组件地址信息相对应的组件所属组件供应商的权限值，则所述方法还包括：

步骤S404：获取与所述组件地址信息相对应的组件供应商的证书信息；

步骤S405：依据获取的证书信息，计算与所述资源访问请求信息相对应的访问者对与所述待访问资源信息相对应的组件资源的权限值；

步骤S406：依据计算的权限值生成第二授权信息，所述第二授权信息表明允许与所述资源访问请求信息相对应的访问者以计算得到的权限值对与所述访问资源信息相对应的组件资源进行访问。

参考图6，其示出了本申请提供的一种组件部署装置实施例三的结构示意图，所述装置包括：

请求获取单元601，用于获取组件部署请求，所述组件部署请求包括组件标识信息；

证书提取单元602，用于若预设的部署规则成立，提取所述组件部署请求中包含的签名证书信息；

证书获取单元603，用于获取OSGi框架配置文件中的第二证书列表；

签名认证单元604，用于标记所述第一证书列表中与所述第一证书列表中相同的证书信息，将所述第一证书列表中被标记的证书信息作为有效证书信息；

逻辑判断单元605，用于判断所述有效证书信息是否满足预设签名规则，如果是，触发组件部署单元606；

所述组件部署单元606，用于将与所述组件标识信息相对应的组件置入所述OSGi框架中。

由上述方案可知，本申请提的一种组件部署装置实施例三，在获取组件部署请求之后，若预设的部署规则成立，提取所述组件部署请求中包含的签名证书信息，获取OSGi框架配置文件中的第二证书列表，标记所述第一证书列表中与所述第一证书列表中相同的证书信息，将所述第一证书列表中被标记的证书信息作为有效证书信息，若所述有效证书信息满足预设签名规则，将与所述组件标识信息相对应的组件置入所述OSGi框架中，由此实现组件的安全部署，相对于现有技术中的组件部署方案，通过对组件的签名进行认证实现安全部署，既而在保证组件安全部署的前提下，明显提高了组件部署的效率。

优选的，所述预设签名规则为所述有效证书信息的有效公钥信息与所述第二证书列表的有效公钥信息相同，且所述有效证书信息的签名主体与所述第二证书列表中的签名主体相同；

若所述有效证书信息不满足预设签名规则，所述逻辑判断单元605还用于结束当前组件部署。

参考图7，其示出了本申请提供的一种组件部署装置实施例三的另一结构示意图，其中，所述预设的部署规则为所述组件部署请求表明需要对与所述组件标识信息相对应的组件进行安全部署；

所述证书提取单元602，还用于若所述预设的部署规则不成立，触发所述组件部署单元606。

参考图8，其示出了本申请提供的一种组件部署装置实施例四的结构示意图，所述装置还包括：

权限表生成单元607，用于预先依据所述OSGi框架配置文件中组件供应商的配置信息，生成所述OSGi框架的组件资源的权限表；

访问信息获取单元608，用于获取组件的资源访问请求信息，所述资源访问请求信息包括组件地址信息及访问资源信息；

权限值查询单元609，用于在所述权限表中查询与所述组件地址信息相对应的组件供应商的权限值，若查找到，触发第一信息生成单元610；

所述第一信息生成单元610，用于依据查询到的权限值生成第一授权信息，所述第一授权信息表明允许与所述资源访问请求信息相对应的访问者以查询到的权限值对与所述访问资源信息相对应的组件资源进行访问。

由上述方案可知，本申请提的一种组件部署装置实施例四，在获取组件部署请求之后，若预设的部署规则成立，提取所述组件部署请求中包含的签名证书信息，获取OSGi框架配置文件中的第二证书列表，标记所述第一证书列表中与所述第一证书列表中相同的证书信息，将所述第一证书列表中被标记的证书信息作为有效证书信息，若所述有效证书信息满足预设签名规则，将与所述组件标识信息相对应的组件置入所述OSGi框架中，由此实现组件的安全部署，进一步的，在组件完成安全部署之后，对该组件访问资源文件的权限进行验证，相对于现有技术中的组件部署方案，通过对组件的签名进行认证实现安全部署，同时通过对组件的权限进行验证保证资源文件的安全，既而在保证组件安全部署的前提下，明显提高组件部署的效率的同时，提高OSGi框架资源文件的安全性。

优选的，参考图9，其示出了本申请提供的一种组件部署装置实施例四的另一结构示意图，所述装置还包括证书信息获取单元611、权限值计算单元612及第二信息生成单元613，其中：

所述证书信息获取单元611，被所述权限值查询单元609在所述权限表中未查询到与所述组件地址信息相对应的组件所属组件供应商的权限值触发，用于获取与所述组件地址信息相对应的组件供应商的证书信息；

所述权限值计算单元612，用于依据获取的证书信息，计算与所述资源访问请求信息相对应的访问者对与所述待访问资源信息相对应的组件资源的权限值；

所述第二信息生成单元613，用于依据计算的权限值生成第二授权信息，所述第二授权信息表明允许与所述资源访问请求信息相对应的访问者以计算得到的权限值对与所述访问资源信息相对应的组件资源进行访问。

本申请还提供了一种安全框架实施例五，所述安全框架包括如上述实施例中任意一项所述的组件部署装置，其中：

所述组件部署装置，用于获取组件部署请求，所述组件部署请求包括组件标识信息；若预设的部署规则成立，提取所述组件部署请求中包含的签名证书信息；其中，所述签名证书信息包括第一证书列表，所述第一证书列表包括至少一条证书信息；获取OSGi框架配置文件中的第二证书列表；标记所述第一证书列表中与所述第二证书列表中相同的证书信息；将所述第一证书列表中被标记的证书信息作为有效证书信息；若所述有效证书信息满足预设签名规则，将与所述组件标识信息相对应的组件置入所述OSGi框架中。

优选的，所述预设签名规则为所述有效证书信息的有效公钥信息与所述第二证书列表的有效公钥信息相同，且所述有效证书信息的签名主体与所述第二证书列表中的签名主体相同，若所述有效证书信息不满足预设签名规则，所述装置还用于结束当前组件部署。

优选的，所述预设的部署规则为所述组件部署请求表明需要对与所述组件标识信息相对应的组件进行安全部署，若所述预设的部署规则不成立，所述装置还用于直接执行所述将与所述组件标识信息相对应的组件置入所述OSGi框架中。

优选的，预先依据所述OSGi框架配置文件中组件供应商的配置信息，生成所述OSGi框架的组件资源的权限表；

在所述将与所述组件标识信息相对应的组件置入所述OSGi框架中之后，所述装置还用于：

优选的，若在所述权限表中未查询到与所述组件地址信息相对应的组件所属组件供应商的权限值，所述装置还用于：

获取与所述组件地址信息相对应的组件供应商的证书信息；

依据获取的证书信息，计算与所述资源访问请求信息相对应的访问者对与所述待访问资源信息相对应的组件资源的权限值；

依据计算的权限值生成第二授权信息，所述第二授权信息表明允许与所述资源访问请求信息相对应的访问者以计算得到的权限值对与所述访问资源信息相对应的组件资源进行访问。

需要说明的是，上述组件的权限表即有效权限集合，是局部权限(可选)和系统权限的交集。局部权限可通过配置文件进行设置，是组件实际需要的操作权限。当组件完成安全部署后初始化该系统权限，通过保护域初始化权限表中预定义的条件和权限值来实现（计算获得）。在基于java安全权限检查时，发起请求的调用组件的保护域先检查局部权限，如果检查失败则整个检查过程失败，表示调用组件不能访问被请求的组件；否则，调用组件的保护域检查调用组件的权限表是否有请求被调用组件的有效权限。

需要说明的是，调用组件的局部权限检查即调用组件的可配置权限表中是否隐含请求被调用组件的访问权限。而调用组件的条件权限检查即调用组件的保护域检查调用组件的条件权限表是否隐含请求被调用组件的访问权限。为了计算隐含的请求权限，调用组件的保护域需要在它的所有满足条件的权限表格中查找到一个隐含了该请求权限的元组。该条件权限表设置以及条件权限检查通过开放式部署通道实现

例如，参考图10，其示出了本申请提供的一种安全框架实施例五的示例图。

其中，所述Equnix或Felix是OSGi规范核心的实现框架之一（简称OSGI核心框架），虽是以Bundle的形式存在,但它们是系统Bundle，能够提供对Bundle安装、卸载、解析、启动、停止等一系列有关Bundle管理的功能。Bundle拥有自己的生命周期，它包括以下状态：Installed(安装过的),resolved(启动就绪或已经停止的)、STARTING(启动中的)、ACTIVE(正在运行的)、STOPING(停止中的)、UNINSTALLED(卸载过的)、UNRESOLVED(不可解析的)、UPDTAED(更新后的)。OSGi框架提供Bundle生命周期管理即对Bundle的功能调用都会更新Bundle的状态，其规范对应OSGi的生命周期层；操作者任何试图访问Bundle资源包括调用它的方法都会引起安全服务提供者对Bundle的权限检查，其规范对应OSGi的安全层。

为能让第三方应用程序扩展安全服务，OSGi框架遵循JCA框架体系结构引入一种基于服务提供者的安全规范，它允许通过ServiceProvider Interface（服务提供者接口，SPI）安插多种安全机制，有独立的算法和协议，可以实现不同的安全操作。OSGi核心框架定义安全服务提供者对服务提供者的安全规范进行描述，支持安全服务提供者的接口发布、缺省实现和方法调用。其中，Felix框架为安全服务提供者定义的接口org.apache.felix.framework.ext.SecurityProvider(简称SecurityProvider)。SecurityProvider接口主要规范对Bundle和Bundle访问者权限的检查的行为，如对Bundle的检查规范成checkBundle方法、对是否有访问Bundle的权限规范成hasBundlePermission方法、获取签名相关数据的信息getSignerMatcher方法，允许除OSGI核心框架的其他应用程序实现并扩展。

OSGI核心框架有关安全服务提供者的功能应用如：当安装Bundle时OSGI核心框架先用安全服务提供者对Bundle进行检查,符合预期结果才继续安装部署该Bundle；当访问者请求访问Bundle资源时，OSGI核心框架先用安全服务提供者对访问者进行权限检查，确认有该项权限时才对该项权限允许的Bundle资源进行对应的操作。

其中，对图10中所述安全框架的具体描述如下：

1.本申请实施例的安全框架基于OSGi规范扩展安全协议，基于Felix框架提供安全服务提供者的实现、权限管理的实现和配置，以Bundle形式提供应用与服务。

本安全框架提供的服务包括为Bundle的安全管理提供实现与相关配置、为被签名的Bundle提供签名认证、为第三方请求访问或调用被安全部署的组件的资源时提供权限检查（基于安全服务提供者），以此来实现安全框架的高可配与可控制，支持开放式部署，确保组件的安全部署和组件资源的安全。

Felix框架安装Bundle时,Bundle被Felix框架实例化成对应的org.apache.felix.framework.Bundle对象并构建它的资源有关的数据模型org.apache.felix.framework.Module对象。

2、所述安全框架提供安全配置的具体描述如下：

使用安全框架配置文件Security.properties，提供对预设组件供应商的信任库文件、信任库类型、信任库私有密钥，以及安全框架是否生效的开关项的配置。其中，所述信任库（keystore文件）包括密钥仓库和证书信息。其中，Security.properties配置内容示例如下：

//OSGi框架的信任库文件地址，文字流处理后解析为第一证书列表

felix.keystore=${loong.base}/conf/cvicse.keystore；

//信任库文件的访问密钥即信任库的私有密钥

felix.keystore.pass=abcd1234|abcd1234|abcd1234；

//信任库类型，若签名则提供对应的签名算法

felix.keystore.type=JKS|JKS|JKS；

//安全框架的启用开关,1为启用，0为不启用

framework.security.turnon=0。

每一个信任库必须有对应的信任库类型和私有密钥。felix.keystore配置信任库文件路径(文件扩展名为.keystore)；felix.keystore.pass配置相应的信任库的私有密钥，felix.keystore.type配置相应的信任库类型。

当Security.properties配置项的值被变更时，触发的变更事件被安全框架监听，安全框架重新读取该配置项的值并应用，以此实现安全管理器动态配置。如安全框架的动态启停就不需要重启框架。

3、图10中所述安全框架功能实现描述如下：

(1)先读取Security.properties配置确认安全框架是否生效。当framework.security.turno设置为1时，OSGi框架激活(启用)安全框架，提供安全框架的安全服务提供者的实现覆盖OSGi框架的缺省实现，扩展对Bundle部署、Bundle权限检查的安全控制;当framework.security.turnon设置为0时，安全框架不被激活(启用)，OSGi框架的安全服务提供者不做扩展，使用缺省实现；

(2)安全框架被启用时，通过安全配置文件的密钥类型实例化信任库(java.security.KeyStore)对象，再根据安全配置文件配置的信任库地址、私钥密码通过文件流形式加载信任库文件以及获取它的证书列表即第一证书列表；

(3)当签过名的待部署组件开始部署到OSGi框架时，本安全框架提供者提供checkBundle方法的实现为签过名的Bundle组件进行签名认证，具体如下：

(3.1)先根据Java提供的安全接口(java.security.*)和OSGi规范获取该组件的资源，重点包括组件中签名时关联的签名证书列表即第二证书列表，也提供解析获取组件以文件形式配置的撤销了的证书列表即第三证书列表。

(3.2)然后将第二证书列表与第一证书列表、第三证书列表筛选，获取第二证书列表中的证书是第一证书列表中的而非第三证书列表的即可信证书。判断第一证书是其他证书列表的证书是根据证书的签名是否在有效期、签名主体是否一致、公钥密码是否相同来进行判定。

(3.3)若有可信证书，则表示该待部署组件签名认证通过，它是可信的，将被置入OSGi框架内，否则不允许。

(4)完成签名认证后，依托Bundle就可以将一个负责人与一系列的权限关联（通过条件权限管理提供创建具有证书的Bundle对象和保护域实现），OSGi框架对所有负责人签名的Bundle都授予其关联的权限。授权是控制操作者（即人、进程和计算机、OSGi框架、Bundle）对系统资源的访问权限的过程，操作者通过OSGi框架来授权，而授予的权限不会超过局部权限。Bundle另一个hasBundlePermission方法提供对Bundle的权限或条件的权限检查。当本安全框架以Bundle部署在OSGi框架内时，创建了一个Bundle同时，也创建了一个对应的惟一的Bundle保护域，这个保护域通过初始化在权限表格中定义的条件和权限值为Bundle计算其系统权限，计算过程中允许删除Bundle不会使用的部分，并优化其经常使用的条目。在本安全框架启动时，该安全框架根据安全配置文件和信任库组建该安全框架Bundle权限集(Permissions)和局部权限集(LocalPermissions),然后在此基础上创建权限管理和条件权限管理。

如图11所示，为本申请提供的安全框架实施例五对Bundle签名认证的时序图，简要叙述如下：

1、创建Bundle对象时，调用安全服务提供者的检测Bundle的方法：checkBundle()；

2、checkBundle()方法调用Bundle签名解析器的方法验证签名的方法checkDNChains()；

2.1、获取证书集的方法getDNChains()；

2.1.1、获取有效的受信任根证书的方法getRootChains()；

2.1.1.1、判断证书是否在撤销列表中以及是否有效的方法trusted()；

2.1.1.1.1、获取证书列表的方法getCaCerts()；

2.1.1.1.1.1、初始化信任库的证书和被撤销的证书列表的方法init()；

需要说明的是，OSGi框架通过文件流读取jar文件，先读取jar文件中签名后产生的两份签名文件以及Bundle描述文件MANIFEST.MF，根据OSGi和Java安全规范解密相关的文件和签名信息，获取对应的签名时保存的证书列表即第二证书列表以及自配的证书列表即第三证书列表；待部署Bundle被OSGI框架进行部署的过程，即为读写jar文件。

其中，图11中Bundle签名解析器(BundleDNParser)提供解析Bundle资源获取证书链以及筛选出对应的第二证书列表(getDNChains())、获取Bundle证书列表（getCertificates()）、检查Bundle证书是否签名以及签名是否正确(checkDNChains())。

而证书管理(TrustManager)提供根据对Bundle有关证书信息的解析，getCaCerts()方法获取第二证书列表，getCRLs()方法获取第三证书列表。

安全框架的安全服务提供者(SecurityProviderImpl)，是SecurityProvider接口的实现类，提供权限检查、Bundle检查和获取签名匹配器对象方法的实现。

安全服务提供者的checkBundle方法先使用信息管理(TrustManager)的getCaCerts()获取第二证书列表和getCRLs()获取第三证书列表,然后调用匹配器(BundleDNParser)的checkDNChains()将第二证书列表和第一证书列表与第三证书列表一一匹配获取Bundle的可信证书。如果存在可信证书则通过安全认证，允许框架继续读写待部署组件文件，完成安全部署，否则安全框架抛出异常终止部署进程。

其中第一证书列表在安全框架被激活时，由SecurityGuarder对象解读安全配置文件后缓存配置项的值，以便信息管理加载信任库获取它的证书列表。

简要说明权限管理流程图，如图12所示，分解各关键步骤：

1、OSGi框架用OSGI本安全框架使用安全框架的安全服务提供者检查传参Bundle对象权限的方法hasBundlePermission()；

2、确认权限管理服务对象是否存在，存在则调用权限管理服务的方法检查权限表并返回结果hasPermission();

2.1、确认是否缓存Bundle location位置的权限表，如果有则调用权限管理服务检查权限表返回结果；

2.2、检查权限表是否包含传参权限对象的方法check()即权限管理服务的check()方法，用于检测传参Bundle的权限表是否包含传参权限;

是否缓存传参Bundle location位置的权限表，需要通过权限集的getImplicit方法和Bundle对象获取缺省的权限信息组后使用权限集的getPermissions()方法获取权限集对象或创建该对象，该对象缓存或可解析出传参Bundle的权限表。其中缺省权限信息组属性值名称描述为Bundle的唯一标识符，类型为AdminPermission类名称以及动作描述包括”METADATA”、”CONTEXT”、”RESOURCE”。

2.2.1获取权限集对象或创建该对象方法getPermissions()即权限集的静态方法getPermissions()；

2.2.2、计算权限方法implies()即权限集的implies()方法，用于批量计算权限信息描述的权限是否包含传参Bundle对象权限；

2.3、location位置的权限表无缓存的权限表且条件权限管理服务存在，传参权限又不是局部权限，则返回NULL；

2.4、无缓存权限表且条件权限管理服务不存在或传参权限为局部权限方法impliesLocal(),impliesLocal()为条件权限管理服务的方法。

2.4.1、有缺省权限列表则检查是否包含传参权限方法check()；

2.4.2、不然检查传参Bundle的权限表是否包含传参权限方法check()；

2.4.3、获取权限集的方法getPermissions()、计算权限的方法implies()；

3、步骤2返回结果不为NULL,参数Bundle域是否有满足条件的参数权限handlePAHandle即条件权限管理服务的方法handlePAHapdle()，并返回结果；

4、条件权限管理服务检查Bundle的权限是否包含传参权限的方法hasPermission()，并返回结果。

需要说明的是，本安全框架为OSGi框架提供安全层的扩展和实现，允许嵌入权限管理或条件权限管理服务，集成开放式安全部署、对签名过的Bundle进行认证与权限检查，同时提供安全服务提供者、安全策略、保护域、条件权限服务、权限服务、开放式安全部署等规范与定义的实现。

安全框架的权限集(Permissions)默认被授予该Bundle对自身资源进行安全控制的通用权限，如文件进行读写删除的权限，类资源加载权限、Bundle管理权限等。

以下对安全框架中涉及到的类进行说明：

数据建模(包括JDK和OSGi规范提供的接口和类)：

权限(Permssion)java.security.Permission，JDK（Java Development Kit）提供的表示访问系统资源的抽象类。所有权限都有一个名称，以及抽象方法implies()、checkGuard()、getActions()等，具体参考jdk规范。

条件式(Condition)org.osgi.service.condpermadmin.Condition，OSGi规范提供的接口，规范了对条件的行为，如返回条件是否易变的方法isMutable()、返回计算是否必须延迟到权限检查的最后进行的方法isPostponed()、返回是否满足条件的方法isStatisfied()等。条件式组存在于条件权限管理服务，目的在于确定是否应有一个权限集合。因此，当条件权限管理服务检查传参Bundle的有效权限集来检查和传参权限对象时，有效权限集或缺省的带条件的权限集包含传参权限且是带条件的，则必须计算该权限的条件式组的条件式，以确认对应权限是否满足所有的条件。安全框架可配置缺省的带条件的权限集。

权限信息(PermissionInfo)org.osgi.service.permissionadmin.Permissio-nInfo，OSGi规范提供的描述权限的类，其属性包含类型描述、名称描述、动作描述，类型均属java.lang.String。

条件信息(ConditionInfo)org.osgiosgi.service.condpermadmin，OSGIOSGi规范提供的类，属性包含一个String类型参数组args和一个类型描述type；条件信息用于描述条件式，它的属性类型type描述Condition的实现类的类路径，以便条件式集计算条件式时可通过反射机制调用Condition实现类的getCondition()获取新增的条件式对象。

条件权限信息(ConditionalPermissionInfo)org.osgi.service.condperma-dmin.ConditionalPermissionInfo，OSGi规范提供的接口，关联一组权限信息和一组条件信息。条件信息组和权限信息组可看成带条件的权限表，该权限表是条件信息对象集合和权限信息的集合的笛卡儿积。该实现类还扩展对权限信息组与条件信息组的获取，权限信息组与条件信息组的计算，便于更好的实现条件权限管理服务。

实现类org.trustie.loong.framework.security.condpermadmin.Condition-alPermission InfoImpl，其属性包括一组ConditionInfo即条件信息组、一组PermissionInfo即权限信息组以及参数构造的条件权限管理服务实例引用m_cpai。

构造方法传参赋值属性,有方法getConditionInfos()获取条件信息组、获取权限信息组方法getPermissionInfos()、解析权限信息方法parseConditionInfo()、解析条件信息方法parsePermissionInfo()以及writeTo()方法将解析后的信息对应写入到该属性条件信息组和权限信息组进行缓存等。

其中，条件式集(Conditions)org.trustie.loong.framework.security.util.C-ondtions，集中管理权限表的条件信息组，建立并管理Bundle、条件信息组、条件式组之间的关联集，提供条件计算等，其属性：

Bundle资源模型、条件信息组以及条件式组关联集：

private static final Map<Module,Map<ConditionInfo[],Condition[]>m_conditionCache=new WeakHashMap()；

条件信息组、Bundle资源模型与条件式集关联集：

private final Map<ConditionInfo[],Map<Module,Conditions>>m_cache=new WeakHashMap()；

Bundle资源模型：private final Module m_module；

条件信息组：private final ConditionInfo[]m_conditionInfos；

条件式组：private final Condition[]m_conditions；

安全动作对象：private final SecureAction m_action。

其中，条件信息组集中缓存Bundle的条件信息，条件式组集中缓存Bundle的条件式，用于集中计算条件；安全动作对象，集中提供具有系统级安全控制访问系统资源的方法，如获取类加载器、根据类对象获取方法实体等；Bundle资源模型对象来源Bundle保护域(BundleProtectionDomain)的getModule()方法调用，可以获取Bundle的基本资源，如Bundle版本、id、声明策略、扩展状态和相关上下文等。

方法如下：

集中计算权限的条件式组，返回true或false：public booleanisSatisfied(List posts,Permissions permissions,Permission permission)。

其中，isStatisfied方法先遍历m_conditionInfos,根据ConditionInfo的type作为ClassName使用反射机制获取条件式对象，当传参权限集包含传参权限且使用条件式对象的isPostponed()方法获取为TRUE表示需要延迟计算时，则将条件式缓存到posts(可向外传递)；当条件式对象计算不延迟且调用条件式对象的isStatisfied()进行计算获得结果为False则代表条件不满足则直接返回False结束isStatisfied方法调用，否则表示当前的条件式对象的条件满足，继续下一轮的条件计算。该方法最终返回为true代表权限检查，那么就称之为满足条件，如果抛出了异常或是任何一个条件返回为false则将这种情况看作是不满足条件。

获取条件式集：public Conditions getConditions(Module key,ConditionInfo[]conditions)。

其中，getConditions()方法先根据传参信息key和conditions从m_cache缓存集中获取Conditions对象，若存在则返回，不存在则新建条件式组集对象，然后缓存到m_conditionCache和m_cache后返回该对象。当条件权限管理服务调用eval()方法计算条件权限时使用该方法。

条件权限信息集的条件式计算：public boolean evalRecursive(Listentries)，判断条件权限信息集的条件式是否满足安全框架对应权限的条件式。

权限集(Permissions)org.trustie.loong.framework.security.util.Permissi-ons：以集合形式管理权限以及权限信息组（带有字符串编码的权限对象），提供通过缓存的权限信息来判断是否有访问参数文件的权限,提供获取有权限信息组对应的权限集，提供implies()方法对传参Bundle权限表的某权限与传参权限进行匹配。

局部权限集(LocalPermissions)：org.trustie.loong.framework.security.ut-il.LocalPermissions，其属性如下：

局部权限缓存表：private final Map m_cache=new WeakHashMap()，可以缓存配置权限，通过使用OSGI-INF/permissions.perm文件声明自己需要的权限，格式为UTF-8编码，如果未配置则默认为一般权限。

方法如下：

局部权限表内是否包含参数权限：public boolean implies(Contentcontent,Bundle Bundle,Permission permission)，支持permissions.perm文件解析设置局部权限缓存表，根据权限信息获取权限集implies方法进行计算；

签名解析器(BundleDNParser)：org.trustie.loong.framework.security.ve-rifier.BundleDNParser，是解析签名证书和检查签名信息的工具，签名的资源包括Java源码（java.security.CodeSigner）、证书序列、证书（java.security.cert.CertPath）。其功能包括根据Bundle的JAR文件加载成java.util.jar.JarEntry对象，然后根据该对象的getCodeSigners方法获取JAR包的签名源码组、批量调用CodeSigner的getSignerCertPath方法获取证书序列，根据证书序列（不可变的证书路径及不同类型的证书（X.509、PGP等））获取Bundle不同签名类型的证书。Bundle的签名类型包括受信任的、所有的；

安全服务提供者(SecurityProvider)org.apache.felix.framework.ext.Se-curityProvider，主要提供规范hasBundlePermission方法检查Bundle权限、checkBundle方法检查Bundle、getSignerMatcher方法获取签名匹配器;

安全框架提供SecurityProvider接口的实现类org.trustie.loong.frame-work.SecurityProviderImpl，其属性：

private final BundleDNParser m_parser；//签名解析器

private final PermissionAdminImpl m_pai；//权限管理服务

private final ConditionalPermissionAdminImpl m_cpai；//条件权限管理服务

private final SecureAction m_action；//安全动作对象

private BundleContext bc。//Bundle上下文

其方法有：

构造方法：SecurityProviderImpl(BundleContext bc,String crlList,String typeList,String passwdList,String storeList,PermissionAdminImplpai,ConditionalPermissionAdminImpl cpai,SecureAction action)，当安全框架激活时调用该构造方法创建安全服务提供者的实例并属性赋值；

Bundle权限检查方法：public booleanhasBundlePermission(BundleProtectionDomain,Permission permission,boolean direct)，由核心框架调用该方法，实际使用条件权限管理服务或权限管理服务的hasPermission、handlePAHandle方法判断参数Bundle域是否有参数权限；

Bundle检查方法：public void checkBundle(Bundle Bundle)throwsException,由核心框架部署参数Bundle时调用，实际使用签名解析器checkDNChains方法对Bundle的签名进行认证；

获取签名匹配器对象：public Object getSignerMatcher(final BundleBundle,int signersType);-由核心框架获取签名匹配器时调用该方法，实际使用匹配器的getDNChains方法获取证书列表。

权限管理服务(PermissionAdmin)：

org.osgi.service.permissionadmin.PermissionAdmin，其实现类org.osgi.service.permissionadmin.PermissionAdminImpl，其属性有：

PermissionInfo[]m_default=null；//缺省权限列表

final Map<String,PermissionInfo[]>m_store=new HashMap()；//缓存Bundle location位置与权限信息组映射的集

final Permissions m_permissions。//缓存权限集，数据来源安全框架启动时的缺省设置

其方法有：

获取一个位置列表即m_store的关键字组：getLocations()；

获取location对应的权限信息组：PermissionInfo[]getPermissionns(St-ring location)，若在m_store中具有对指定位置location的PermissionInfo对象返回PermissionInfo对象的列表，否则那么返回null；

设置location对应的权限信息组：setPermissions(String location,PermissionInfo[]permissions)，对m_store进行管理。若对应的location位置有相应的权限描述组则将它们分别作为key/value缓存到m_store,没有则从m_store移除location位置对应的权限；

获取缺省权限列表：getDefaultPermissions()，返回缺省权限列表m_default，可以将这些权限赋予给所有那些在权限表中没有条目的Bundle；

设置缺省权限列表m_default：setDefaultPermissions(PermissionInfo[]permissoinInfos)；

权限检查：hasPermission(String location,Bundle bundle,Permissionpermission,ConditionalPermissionAdminImpl cpai,ProtectionDomain pd,Content content)，计算bundleBundle权限，判断Bundle对应传参权限是否满足安全框架预设条件或传参Bundle对应权限预设条件，实际使用到check()方法;当安全服务提供者使用hasPermission()方法时使调用用到该方法；

检查权限：check(PermissionInfo[]permissions,Permission permission,Bundle bundle)，缓存m_permissions中调用getPermissions()添加或直接获取Permissions对象调用implies()方法判断permission是否存传参Bundle权限表内；

条件权限管理服务(ConditionPermissionAdmin)：org.osgi.service.condperm-admin.ConditionalPermissionAdmin。

实现类：

org.trustie.loong.framework.security.condpermadmin.ConditionalPermi-ssionAdminImpl：

其属性：

条件权限信息集：Map m_condPermInfos=new OrderedHashMap()，由安全框架启动时传参设置，默认数据来源配置文件cap.txt的读取，当本类方法操作条件信息对象时同步该缓存集；

PropertiesCache m_propertiesCache；//属性缓存对象

Permissions m_permissions；//权限集

private final Conditions m_conditions；//条件式集

private final LocalPermissions m_localPermissions；//局部权限集

private final PermissionAdminImpl m_pai；//权限管理服务。

其方法：

条件权限管理服务检查是否包含权限方法：public booleanhasPermission(Module module,Content content,ProtectionDomain pd,Permission permission,boolean direct,Object admin)；

条件权限管理服务计算获取检测Bundle权限的条件列表方法：

private boolean eval(List posts,Module module,Permissionpermission,Object admin)；

条件权限管理服务匹配Bundle保护域的条件列表方法：publicboolean handlePAHandle(BundleProtectionDomain pd)；

条件权限管理服务确认是否是配置的局部权限方法：public booleanimpliesLocal(Bundle felixBundle,Content content,Permission permission)；

添加条件权限信息并返回该对象的方法：publicConditionalPermissionInfo addConditionalPermissionInfo(ConditionInfo[]conditions,PermissionInfo[]permissions)public ConditionalPermissionInfoaddConditionalPermissionInfo(ConditionInfo[]conditions,PermissionInfo[]permissions)。

系统权限通过条件权限管理服务来进行管理。条件权限管理也可以注册权限管理服务.条件权限管理通过一系列条件来对权限控制。只有当符合条件时才会授予权限。Conditions会请求用户交互，并导致其他影响。其中一个后果就是这种执行条件的处理模型必须是高度优化的。这也就要求框架必须完成权限检查。因此，框架必须利用条件权限管理的一种实现来替代安全管理，而本安全框架就提供了这种实现。这些ConditionalPermissionInfo对象蕴含了所有的Bundle，可以有效的处理缺省权限,这是和权限管理（Permission Admin）中不一样的地方；在权限管理中，只有当没有指定权限集合时才会使用缺省权限。通过使用方法addConditionalPermissionInfo或者方法setConditionalPermissionInfo来将权限添加到元组的权限编码中。这两种方法的不同在于参数名称的不同。可以将ConditionalPermissionInfo对象匿名或者自命名添加权限。每一个ConditionalPermissionInfo对象都具有一个惟一名称用于区分其他ConditionalPermissionInfo对象，同时也将它和一个管理服务器区分开来。如果没有指定名称或者是名称为空，那么条件权限管理服务将自动为它创建一个名称。上述方法都是返回一个ConditionalPermissionInfo对象，可以通过这个对象来访问元组。这些对象也可以通过方法getConditionalPermissionInfos()来进行枚举访问，或者是指定一个名称来调用方法getConditionalPermissionInfo(String)访问。可以通过方法getName()获得返回对象的名称。可以通过方法ConditionalPermissionInfo.delete()来删除一个ConditionalPermissionInfo对象。在元组中包含了一个ConditionInfo对象数组和一个PermissionInfo数组，ConditionalInfo对象和PermissionInfo对象都可以通过编码字符串来组建。条件权限管理中没有缺省权限的情况。

安全属性配置缓存器(SecurityGuarder)，属性：

private int turn_flag；//是否启用安全框架

private String storeList=null；//安全信任库文件的路径

private String passwdList=null；//安全信任库私钥密码

private String typeList=null；//安全信任库类型

private String policy=null。//安全策略

以上属性值皆来自对security.properties的解析获得,此工作由方法init()完成。当安全服务提供商调用checkBundle方法时，初始化该SecurityGuarder对象后调用init()方法解析security.properties，为其属性赋值。

主域组合器(DomainGripper)：java.security.DomainGripper，实现类：org.trustie.loong.framework.security.condpermadmin.DomainGripper

其中，方法如下：

获取当前执行线程的主域组合器收集的主域集public static List grab()-允许收集的保护域(ProtectionDomain)集缓存到该类的私有属性m_domains，获取控制器上下文(AccessControlContext)缓存到私有属性m_system；

动态更新与当前AccessControlContext关联的保护域的方法：pu-blic ProtectionDomain[]combine(ProtectionDomain[]current,ProtectionDom-ain[]assigned)。

权限检查的关键步骤：

当访问者需要使用Bundle资源时，OSGi框架会使用本安全框架的安全服务提供者的hasBundlePermission方法检查Bundle的权限是否包含在安全框架的权限表，方法返回布尔类型值(即true或false，true表示该安全框架权限检查Bundle权限存在，false则不存在)。在此之前，安全框架作为Bundle激活时实例化安全服务提供者、条件权限管理服务和权限管理服务这三个类,同时将解析配置文件和信任库文件后得到的相关数据存储在SecurityGuarder实例对象属性中。

安全服务提供者的hasBundlePermission方法检查Bundle权限时，本方法提供对权限管理服务和条件权限管理服务的应用。

根据安全服务提供者的hasBundlePermission方法参数ProtectionDomain获取Bundle对象、Bundle的模型对象以及Bundle对应的location字符串。location是Bundle的位置字符串，可以唯一标识一个Bundle,访问对象可通过资源访问对象的getLocation()获取Bundle的location字符串。

A、如果存在权限管理服务对象，则使用权限管理服务对象检查权限返回Boolean值（此方法详细步骤参考以下标记(a.1)）存储于Boolean类型变量result,若result不为NULL接续B,result为NULL接续C。

B、然后result不为NULL则继续判断，如果条件权限管理服务对象存在且保护域不是直接的即传参对象direct为false，则判断result结果的Boolean是否为false,为false则返回结果，为true则调用条件权限服务对象的handlePAHandle方法检查权限返回Boolean值(此方法详细步骤参考以下标记(b.1))结束检查;如果条件权限管理服务对象不存在或者传参对象direct为true，则直接返回result结果。

C、result为NULL且存在条件权限管理服务对象则调用它的hasPermission方法检查权限返回Boolean值结束检查;

(a.1).权限管理服务对象检查传参ProtectionDomain的Bundle权限表是否包含传参权限时，使用它的hasPermission方法,返回Boolean值。此方法按以下步骤完成的工作流程：

(a.1.1)先判断该安全框架的权限管理服务对象的属性m_store是否包含传参ProtectionDomain对应location的关键字，有则进行(a.1.2)，无则(a.1.3),否则返回NULL；

(a.1.2)如果通过location位置字符串为关键字从Map对象m_store中获取权限信息组不为NULL即权限信息组不为NULL则作为参数调用权限管理服务对象的check方法返回结果，结果返回TRUE则结束调用，返回FLASE则继续从权限管理服务对象的另一个属性即m_permissions调用权限集的getImplicit方法根据Bundle对象获取权限信息组，作为参数第二次调用check方法,返回Boolean值后结束调用。

(a.1.3)接续(a.1.1),如果条件权限管理服务对象为NULL或者其属性m_condPermInfos为NULL且调用其impliesLocal方法返回为TRUE则继续判断，判断权限管理服务对象的属性m_default是否为NULL,为NULL则返回TRUE,不为NULL则将m_default作为参数调用check()方法返回,返回TRUE则结束调用，返回FLASE则继续从权限管理服务对象的另一个属性即m_permissions调用权限集的getImplicit方法根据Bundle对象获取权限信息组，作为参数第二次调用check方法,返回Boolean值后结束调用。

其中m_store、m_permissions的值源自权限管理服务对象的构造方法参数赋值，当权限管理服务对象的setDefaultPermissions()、setPermissions()时允许更新m_store缓存对象并写入到文件，缓存权限权限管理服务对象的默认权限包括对安全框架作为Bundle的管理权限(如资源的读写权限、上下文的访问权限),即m_permissions为本安全框架的缺省权限集；权限管理服务对象的check方法具体调用的是传参对象Permissions的implies方法进行权限计算。

权限管理服务对象的check方法具体对传参权限信息组、Bundle的权限对象进行计算、具体根据传参权限信息组作为m_permissions方法的getPermissions()参数获取相应的权限集对象，调用权限集对象的implies计算传参Bundle的权限表是否包含传参权限对象。

条件权限管理服务对象的impliesLocal方法调用局部权限集对象的implies方法进行计算.其中参数content值来自Bundle模型对象的getContent()方法调用。

局部权限集的implies方法具体实现：先判断Map类型的属性对象m_cache的关键字是否有content，有则从缓存中获取权限信息组，无则读取permissions.perm配置文件组建权限信息组,由权限信息组创建权限集并调用权限集的implies方法进行计算。

(b.1)条件权限管理服务对象的handlePAHandle方法调用，先m_stack.get()方法获取条件权限信息集，有则作为参数调用m_conditions.evalRecursive方法，没有则从通过DomainGripper的grab方法利用AccessController.doPrivileged()和AccessControlContext方法获取当前执行线程中保护域集合，保护域集合删除传参BundleProtectionDomain对象后仍不为NULL，则缓存到m_stack并返回TRUE,保护域集合删除传参BundleProtectionDomain对象后为NULL，则根据对应的条件权限信息集调用条件权限管理服务对象的evalRecursive方法并返回Boolean值。

(c.1)条件权限管理服务对象的hasPermission方法调用，先以Boolean类型传参对象direct初始化List类型变量tuples即缓存的条件权限信息集和domains即保护域集。

如果direct为true则domains只缓存传参ProtectionDomain对象,不为false则使用m_stack.get()方法获取对象组，对象组为NULL则通过DomainGripper的grab方法获取保护域集和new ArrayList()赋值，然后加载到对应的变量tuples和domains内缓存，且m_stack.set(null)；

(c.2)然后使用条件权限管理服务对象的impliesLocal方法确认传含局部权限集是否包参权限，如果是则继续，不是则返回flase结束检查；

(c.3)再调用条件权限管理服务对象的eval方法计算权限，返回值存储于Boolean类型变量result。

(c.3.1)eval方法首先判断权限管理服务对象和缓存属性m_condPermInfo是否都为NULL,如果是则返回TRUE，如果不是则继续；

(c.3.2)m_permissions调用权限集的getImplicit方法根据Bundle对象获取权限信息组，然后调用permissions的getPermissions方法根据权限信息组获取或创建权限集,再调用权限集的implies()方法进行计算，计算结果为TRUE,则返回结果，否则继续；

(c.3.3)如果有条件权限信息集限制即m_condPermInfos有数据，则需要调用该集合每个条件权限信息的条件信息组和权限信息组临时构造条件集和权限集对象，分别调用它们的isSatisfied方法和implies方法对传参权限进行匹配，传参权限如果包含于条件权限信息集内则将传参权限符合的ConditionalPermissionInfoImpl对象用eval方法的传参对象List类型变量posts对象缓存并返回TRUE，反之则返回false。

(c.4)result接收eval方法结果，list类型变量tuples接收posts值，先除去domains缓存的传参对象pd（类型ProtectionDomain）后，如果domains为空则清空m_stack,判断tuples不为NULL时则调用m_conditions的evalRecursive方法来判断tuples的条件权限信息集的条件式是否都满足，结果返回true或false；如果domains不为空则将最新的对象组设置到m_stack后返回result。

其中m_conditions是条件权限管理服务对象的属性,类型List,存储条件权限信息,初始化值由条件权限服务对象的构造方法赋值，安全框架被激活时实例化条件服务对象,它提供newConditionalPermissionInfo()或是addConditionalPermissionInfo()方法更新该数据;m_conditions是条条件权限管理服务对象的属性,类型条件式集,初始化值由条件权限服务对象的构造方法赋值；m_stack是条件权限管理服务对象的属性,类型ThreadLocal，为缓存处理对象，目的便于属性值同步，优选的，可以挪放到对应的类说明中..

(b.4.1)条件式集(Conditions)的evalRecursive方法根据传参对象tuples遍历所有的条件信息对象，判断其中的条件式(Condition)的条件是否都满足，都满足则返回true，反之false；

以下对本申请说明书中涉及的部分概念进行描述：

JSK：(Java Keystore)信任库的Java实现版本，SUN提供的数字证书库，可以在安全套接层(ssl)配置信任库和证书库。

JCEKS：（JCE Keystore）信任库的JCE实现版本，SUNJCE提供用于加密、密钥生成和协商以及Message Authentication Code（MAC）算法的框架和实现。它提供对对称、不对称、块和流密码的加密支持，它还支持安全流和密封的对象。

PKCS：全称为Public-Key Cryptography Standards，是由RSA实验室与其它安全系统开发商为促进公钥密码的发展而制订的一系列标准.

BKS：Bouncycastle提供的基于JCE实现的信任库和证书管理。信任库的管理包括生成密钥、加密改密解密等；证书管理：生成证书、证书转换、数字签名、认证管理等。

UBE：Bouncycastle提供的更安全信任库管理技术。

PKCS#7：亦称为加密消息的语法标准，由RSA安全体系在公钥加密系统中交换数字证书产生的一种加密标准。

PKCS#12：为个人信息交换语法标准,一种交换数字证书的加密标准格式，用来描述个人身份信息。如：用户公钥、私钥、证书等。它为了传输、备份、恢复数字证书和它们相关的在公钥加密系统里的公钥或私钥提供供应标准格式。提供用于输出数字证书和它的私钥的输出格式。

X.509证书信息包括主题名称、认证机构、公钥信息(加密算法和主题)、有效日期、扩展证书(图片、指纹编码资源、护照内容等)。

美国政府数字签名标准（DSA）：Digital Signature Algorithm(DSA)是Schnorr和ElGamal签名算法的变种，被美国NIST作为数字签名标准即DSS(DigitalSignature Standard)。

RSA公钥加密算法:1977年由Ron Rivest、Adi Shamirh和LenAdleman在（美国麻省理工学院）开发的。RSA取名来自开发他们三者的名字,已被ISO推荐为公钥数据加密标准。

RSA算法：将两个大素数相乘十分容易，但那时想要对其乘积进行因式分解却极其困难，因此可以将乘积公开作为加密密钥。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

以上对本发明所提供的一种组件部署方法、装置及安全框架进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims

1.一种组件部署方法，其特征在于，所述方法包括：

获取组件部署请求，所述组件部署请求包括组件标识信息；

获取OSGi框架配置文件中的第二证书列表；

2.根据权利要求1所述的方法，其特征在于：

结束当前组件部署。

3.根据权利要求1所述的方法，其特征在于：

若所述预设的部署规则不成立，所述方法还包括：

4.根据权利要求1所述的方法，其特征在于，预先依据所述OSGi框架配置文件中组件供应商的配置信息，生成所述OSGi框架的组件资源的权限表；

5.根据权利要求4所述的方法，其特征在于，若在所述权限表中未查询到与所述组件地址信息相对应的组件所属组件供应商的权限值，所述方法还包括：

获取与所述组件地址信息相对应的组件供应商的证书信息；

依据获取的证书信息，计算与所述资源访问请求信息相对应的访问者，对与所述待访问资源信息相对应的组件资源进行访问的权限值；

6.一种组件部署装置，其特征在于，所述装置包括：

7.根据权利要求6所述的装置，其特征在于：

8.根据权利要求6所述的装置，其特征在于：

9.根据权利要求6所述的装置，其特征在于，所述装置还包括：

10.一种安全框架，其特征在于，包括如上述权利要求6至9任意一项所述的组件部署装置。