83、基于规则的角色供应：结合 OWL 和 F-Logic 的解决方案

基于规则的角色供应：结合 OWL 和 F-Logic 的解决方案

在当今复杂的信息系统中，角色供应和访问控制是保障系统安全和高效运行的关键环节。传统的方法在处理复杂规则和动态变化时存在一定的局限性，而结合 OWL（Web Ontology Language）和 F-Logic 的方法为解决这些问题提供了新的思路。

1. OWL 的局限性与 F-Logic 的引入

OWL DL 在定义本体概念、实例和类的分类法方面具有优势，特别是与 OWL DL 推理机结合使用时。然而，它在支持计算属性方面存在不足。例如，在表达基于规则的用户 - 角色、角色 - 权限和用户 - 权限分配时，需要计算属性来准确表达分配规则。

另外，OWL 在处理否定时采用开放世界假设（OWA），即只有当一个陈述与本体中的其他信息明确矛盾时，才认为该陈述为假。这种弱否定在处理访问控制策略规则时可能导致不安全的策略系统，因为权限可以被明确禁止。

为了解决 OWL DL 的固有局限性，人们尝试了不同的方法来将规则与本体结合或扩展本体。例如，一些系统以 RDF 为核心部分定义语言并扩展以定义规则，如 Jena、TRIPPLE 和 N3Logic；还有描述逻辑程序（DLP），它定义了描述逻辑和声明式逻辑程序（Horn 子句）的交集；以及 SWRL，它向 OWL DL 添加了新的公理（Horn 子句规则）。但这些方法在规则表达能力上都存在一定的限制。

因此，我们采用了一种混合方法。首先使用现有的本体推理机检查一致性并推导类层次结构，然后使用现有的规则推理机支持基于算术表达式和聚合的计算属性，以及与封闭世界假设（CWA）相关的失败否定。我们选择了 F-Logic，它将逻辑编程和演绎数据库的范式与对象、类和类型的概念相结合。我们的供应框架使用了开源系统 Flora - 2，它将 F-Logic 与其他形式主义（如 HiLog 和事务逻辑）集成。

2. F-Logic 规则表达

以下是一些无法用 OWL DL 表达但可以用 F-Logic 规则表达的条件：
- CI（成本中心的总分配成本） ：成本中心有一个计算属性，包含所有分配成本的总和。可以用对象分子作为规则头来表达这个计算属性。

?X[hasT otalAllocatedCosts →?Y ] ←−
?X : CostCenter ∧?Y = sum{?Z|?X[hasCosts →?Z]}.

• CII（成本中心的成本限制） ：成本中心有一个计算属性，指定所有分配成本的限制，每个成本中心的所有分配成本总和不得超过分配预算的 110%。

?X[hasCostLimit →?Y ] ←−
?X : CostCenter ∧?X[hasBudget →?Z] ∧?Y is ?Z ∗110/100.

• CIII（人员的所有代表） ：一个人有一个计算属性，包含所有明确（直接委托）和隐式（传递委托）的代表。可以通过递归规则表达式解决传递委托问题。

?X[hasDelegateAll →?Y ] ←−
?X : Person ∧?Y : Person ∧?X[hasDelegate →?Z]
∧(?Y =?Z ∨?Z[hasDelegateAll →?Y ]).

• CIV（成本中心的所有负责人） ：成本中心有一个计算属性，包含所有负责人，可能的成员包括直接分配的负责人、直接代表和传递代表。

?X[hasResponsibleAll →?Y ] ←−
?X : CostCenter ∧?Y : Person
∧( ?X[hasResponsible →?Y ]
∨( ?X[hasResponsible →?Z] ∧?Z[hasDelegateAll →?Y ]) ).

3. F-Logic 推理

F-Logic 由于其面向对象的概念和基于框架的语法，也可以用作本体语言。OWL 类被建模为一元谓词，属性被建模为二元谓词，而 F-Logic 类和属性被建模为术语。在我们的供应框架中，我们结合了这两种方法，以利用它们的推理和表达优势。为了在多步骤推理过程中使用这两种推理方法，需要在 OWL 和 F-Logic 之间翻译知识库事实。以下是一些翻译规则：
| OWL 语法 | F-Logic 语法 |
| ---- | ---- |
| 类层次结构：C ⊑ D | C::D |
| 概念定义：C ⊑ ∀P.D | C[P ⋆⇒ D] |
| 实例：I ∈ C | I : C |

4. RBAC 策略

框架的一个关键目的是提供适当的方法来建立基于规则的用户 - 角色和权限 - 角色分配，并将这些分配传播到供应目标。用户、角色和权限被建模为 OWL 类，分配被建模为每个类的计算属性。

4.1 用户 - 角色分配规则

以下是一些动态建立用户 - 角色分配的 F-Logic 规则：
- hasRole = “CAA RESTRICTED”

?X[hasRole →CAA REST RICT ED] ←−
?X : User ∧?ZZ[hasUser →?X] ∧?Y : CostCenter[hasResponsible →?ZZ]
∧?XX = sum{?Z|?Y [hasCosts →?Z]} ∧?Y : CostCenter[hasBudget →?Y Y ]
∧?XXX is ?Y Y ∗110/100−?XX ∧?XXX < 10000

• hasRole = “CAA MEDIUM”

?X[hasRole →CAA MEDIUM] ←−
?X : User ∧?ZZ[hasUser →?X] ∧?Y : CostCenter[hasResponsible →?ZZ]
∧?XX = sum{?Z|?Y [hasCosts →?Z]} ∧?Y : CostCenter[hasBudget →?Y Y ]
∧?XXX is ?Y Y ∗110/100−?XX ∧?XXX ≥10000 ∧?XXX < 100000

• hasRole = “CAA UNRESTRICTED”

?X[hasRole →CAA UNREST RICT ED] ←−
?X : User ∧?ZZ[hasUser →?X] ∧?Y : CostCenter[hasResponsible →?ZZ]
∧?XX = sum{?Z|?Y [hasCosts →?Z]} ∧?Y : CostCenter[hasBudget →?Y Y ]
∧?XXX is ?Y Y ∗110/100−?XX ∧?XXX ≥100000

4.2 角色层次结构和权限继承

我们将角色层次结构建模为角色类上的 hasSubRoles 关系属性。每个角色传递地支配其子角色，高级角色获取其低级角色的权限。角色 - 权限分配是基于规则的角色 - 权限分配（计算角色属性 hasPermissions）和由于权限继承规则而继承的分配的并集。

• 计算角色的所有传递子角色

?X[hasSubRolesAll →?Y ] ←−
?X : Role ∧?Y : Role ∧?X[hasSubRole →?Z]
∧(?Y =?Z ∨?Z[hasSubRoleAll →?Y ])

• 计算角色的所有权限

?X[hasPermissionAll →?Y ] ←−
?X : Role ∧?Y : Permission
∧?X[hasSubRolesAll →?Z] ∧?Z[hasPermission →?Y ]

4.3 否定处理

供应框架中存在两个不同的逻辑推理机，OWL 推理机使用开放世界假设（OWA），F-Logic 推理机使用封闭世界假设（CWA）。为了避免弱否定的不受控制使用带来的安全问题，我们建议将规则库中的所有谓词分类为弱或强。框架控制弱谓词在 OWA 下评估，强谓词在 CWA 下评估。

4.4 职责分离（SoD）

RBAC 模型提供职责分离（SoD）来强制执行利益冲突策略，分为静态和动态 SoD 约束。由于我们的框架主要用于推导和供应用户 - 角色和角色 - 权限分配，因此只能应用静态 SoD。

静态 SoD 定义为元组 (R, n)，其中 R 是一组角色，n 是可以分配给单个用户的该组角色的最大数量。在供应 RBAC 元模型中，我们引入了新的类 SoD 约束，它包含一个集合值属性 hasRoles 和一个单值整数属性 hasMaximum。我们还定义了计算属性 hasTransgressingUser 和 hasTransgressingPerson，以及 hasScope 属性来指定 SoD 是应用于本地（用户）还是全局（人员）。

graph LR
    A[Person] -->|hasUser| B[User]
    B -->|hasRole| C[Role]
    D[SoD Constraint] -->|hasRoles| C
    D -->|hasMaximum| E[Maximum]
    D -->|hasScope| F[Scope]
    D -->|hasTransgressingUser| G[User with SoD Conflict]
    D -->|hasTransgressingPerson| H[Person with SoD Conflict]
    B -->|hasSODConflict| G
    A -->|hasSODConflict| H

5. 供应过程

角色供应需要考虑两个方面：基于规则的推理以推断用户 - 角色和角色 - 权限分配事实，以及将这些分配事实供应到目标。我们假设所有供应目标要么实现 SPML（Service Provisioning Markup Language），要么有专门的提供者使目标可用于 SPML 供应操作。

5.1 目标状态

SPML 域模型定义一个供应服务目标（PST）由一个供应服务提供者（PSP）供应，而一个 PSP 可以供应多个 PST。在我们的 RBAC 元模型中，我们定义了目标类，并规定每个用户和权限必须与一个目标相关联。这样，框架可以确定哪个推断的分配事实需要供应到哪个 PST，并确定需要与哪个 PSP 联系以发送格式良好的 SPML 请求。

供应规则控制器需要将推断的分配事实查询出来，并将其转换为与 PST 模式对应的供应服务对象（PSO），同时推导出适当的操作类型（添加、修改、删除、暂停、恢复）。

5.2 实际状态

供应控制器还需要了解每个 PST 中 RBAC 策略的实际状态，以推导出适当的 SPML 操作。SPML 定义了通用方法来确定每个 PST 的实际状态，如 lookup 操作获取序列化的 PSO 及其相关的引用能力数据，search 操作检索 PST 中的所有或部分 PSO（通过 XPath 表达式定义子集）。为了避免过度消耗 PSP 资源，建议使用 update 操作仅检索自上次实际状态推理迭代以来创建、更改或删除的 PSO。

5.3 供应操作

SPML 供应操作取决于推断的目标状态和检测到的 PSO 实际状态。以下是不同实际状态和目标状态组合对应的 SPML 操作：
| 实际状态 | 目标状态 | 操作 |
| ---- | ---- | ---- |
| PSO 标识符 | - | 删除 |
| - | PSO 标识符 | 添加 |
| PSO 标识符 with data’ | PSO 标识符 with data” | 修改 |
| PSO 标识符 with 引用能力数据’ | PSO 标识符 with 引用能力数据” | 修改 |
| 启用的 PSO | 禁用的 PSO | 暂停 |
| 禁用的 PSO | 启用的 PSO | 恢复 |

6. 相关工作

与我们的工作最接近的是 Al - Kahtani 等人提出的 RB - RBAC 模型，该模型自动将用户分配到角色，并允许引入角色优势关系和负授权来诱导角色层次结构。还有基于规则的供应方法区分动态（使用 RB - RBAC 进行供应）和静态（RBAC 管理）用户 - 角色分配，以及 Yu 等人提出的基于 DL 的方法来表示和推理 RB - RBAC。

综上所述，结合 OWL 和 F-Logic 的方法为角色供应和访问控制提供了一种强大的解决方案，能够处理复杂的规则和动态变化，同时保障系统的安全性和高效性。

基于规则的角色供应：结合 OWL 和 F-Logic 的解决方案（续）

7. 供应过程的详细操作步骤

前面我们提到了角色供应过程中的目标状态、实际状态以及相应的供应操作，下面我们将详细阐述这些步骤的具体操作流程。

7.1 目标状态确定流程

graph TD
    A[开始] --> B[查询 RBAC 元模型]
    B --> C[推断用户 - 角色和角色 - 权限分配事实]
    C --> D[确定每个分配事实对应的目标（PST）]
    D --> E[查询分配事实]
    E --> F[将分配事实转换为 PSO]
    F --> G[推导出适当的操作类型]
    G --> H[生成格式良好的 SPML 请求]
    H --> I[结束]

具体步骤如下：
1. 查询 RBAC 元模型 ：从 RBAC 元模型中获取相关信息，包括用户、角色、权限以及它们之间的关系。
2. 推断分配事实 ：使用前面提到的基于规则的推理方法，结合 OWL 和 F-Logic，推断出用户 - 角色和角色 - 权限的分配事实。
3. 确定目标（PST） ：根据 RBAC 元模型中定义的目标类以及用户、权限与目标的关联关系，确定每个分配事实需要供应到的 PST。
4. 查询分配事实 ：供应规则控制器从知识库中查询出这些推断的分配事实。
5. 转换为 PSO ：将查询到的分配事实转换为与 PST 模式对应的供应服务对象（PSO）。这可能涉及到对象模式的翻译，将分配事实的结构映射到 PSO 的结构。
6. 推导操作类型 ：根据分配事实的目标状态和 PST 中 PSO 的实际状态，推导出适当的 SPML 操作类型，如添加、修改、删除等。
7. 生成 SPML 请求 ：根据推导的操作类型和 PSO 信息，生成格式良好的 SPML 请求，以便发送给相应的 PSP。

7.2 实际状态获取流程

graph TD
    A[开始] --> B[确定需要获取实际状态的 PST]
    B --> C[选择合适的 SPML 操作]
    C --> D{操作类型}
    D -- lookup --> E[获取序列化的 PSO 及引用能力数据]
    D -- search --> F[通过 XPath 表达式检索 PSO 子集]
    D -- update --> G[获取自上次迭代以来的 PSO 变化]
    E --> H[更新实际状态信息]
    F --> H
    G --> H
    H --> I[结束]

具体步骤如下：
1. 确定 PST ：明确需要获取实际状态的供应服务目标（PST）。
2. 选择操作 ：根据实际需求和资源消耗情况，选择合适的 SPML 操作，如 lookup、search 或 update。
3. 执行操作 ：
- lookup 操作 ：获取序列化的 PSO 以及与之相关的引用能力数据。
- search 操作 ：使用 XPath 表达式定义 PSO 子集，检索 PST 中的部分 PSO。
- update 操作 ：获取自上次实际状态推理迭代以来创建、更改或删除的 PSO，以减少资源消耗。
4. 更新信息 ：将获取到的信息更新到实际状态信息库中，以便后续与目标状态进行对比。

7.3 供应操作执行流程

graph TD
    A[开始] --> B[对比目标状态和实际状态]
    B --> C{状态组合}
    C -- PSO 标识符 - 无 --> D[执行删除操作]
    C -- 无 - PSO 标识符 --> E[执行添加操作]
    C -- PSO 有数据变化 --> F[执行修改操作]
    C -- PSO 引用能力数据变化 --> F
    C -- 启用 - 禁用 --> G[执行暂停操作]
    C -- 禁用 - 启用 --> H[执行恢复操作]
    D --> I[发送 SPML 请求到 PSP]
    E --> I
    F --> I
    G --> I
    H --> I
    I --> J[PSP 执行操作]
    J --> K[结束]

具体步骤如下：
1. 状态对比 ：将前面确定的目标状态和获取的实际状态进行对比，确定 PSO 的实际状态和目标状态的组合情况。
2. 选择操作 ：根据状态组合，从前面提到的供应操作表中选择相应的操作，如删除、添加、修改、暂停或恢复。
3. 发送请求 ：将生成的格式良好的 SPML 请求发送给相应的 PSP。
4. PSP 执行操作 ：PSP 接收到请求后，根据请求中的操作类型和参数，对 PST 中的 PSO 进行相应的操作。

8. 优势与挑战

结合 OWL 和 F-Logic 进行基于规则的角色供应具有多方面的优势，但也面临一些挑战。

8.1 优势

• 强大的规则表达能力 ：F-Logic 能够表达 OWL DL 无法表达的复杂计算属性和规则，如成本计算、传递委托等。通过 F-Logic 规则，我们可以更精确地定义用户 - 角色和角色 - 权限的分配规则，满足复杂业务场景的需求。
• 灵活的推理能力 ：混合使用 OWL 和 F-Logic 的推理机，能够充分发挥两者的优势。OWL 推理机用于检查一致性和推导类层次结构，F-Logic 推理机用于支持计算属性、聚合以及封闭世界假设下的否定推理，从而实现更全面的知识推理。
• 支持职责分离 ：通过引入 SoD 约束类和相关的计算属性，能够有效地实现职责分离策略，保障系统的安全性和合规性。

8.2 挑战

• 知识翻译成本 ：在 OWL 和 F-Logic 之间进行知识库事实的翻译需要一定的成本，包括定义翻译规则和实现翻译算法。而且，不同的本体结构和语法可能会增加翻译的复杂性。
• 推理机语义差异 ：OWL 推理机使用开放世界假设，F-Logic 推理机使用封闭世界假设，这两种不同的语义在处理隐式知识时可能会产生冲突。需要对规则库中的谓词进行分类，并严格控制其评估环境，以避免安全问题。
• 资源消耗 ：在获取 PST 的实际状态时，如果不合理控制操作，可能会导致 PSP 资源的过度消耗。例如，频繁使用 search 操作查询所有 PSO 会给 PSP 带来较大的负担。

9. 总结

结合 OWL 和 F-Logic 的基于规则的角色供应方法为解决复杂信息系统中的角色供应和访问控制问题提供了一种有效的解决方案。通过利用 OWL 的本体定义能力和 F-Logic 的强大规则表达能力，我们能够更精确地定义和管理用户 - 角色、角色 - 权限的分配关系。同时，通过合理处理职责分离、供应过程中的目标状态和实际状态，以及相应的供应操作，能够确保系统的安全性和高效性。

然而，我们也需要认识到这种方法面临的挑战，如知识翻译成本、推理机语义差异和资源消耗等。在实际应用中，我们需要采取相应的措施来克服这些挑战，如优化翻译算法、严格控制谓词评估环境以及合理使用 SPML 操作等。

未来，随着信息系统的不断发展和安全需求的日益增长，基于规则的角色供应方法有望进一步完善和扩展，为更多的领域提供可靠的角色供应和访问控制解决方案。