fabric1.2.1新特性-访问控制列表

访问控制列表 Access Control Lists(ACL)

什么是访问控制列表？

fabric 使用访问控制列表来通过将策略（在给定一组身份的情况下指定评估为“真”或“假”的规则）与资源关联来管理对资源的访问。在这篇文档中，我们将讨论如何格式化访问控制列表以及如何覆盖默认值。

在做这些之前，必须先了解一些资源和策略的相关知识。

资源

用过通过定位用户链码、系统链码、或者事件流源与fabric进行交互。
应用程序开发人员，需要了解这些资源以及与之关联的默认策略。在configtx.yaml文件中有完整的资源列表。这里有一份configtx.yaml的样例。
在configtx.yaml文件中指定的资源是fabric当前定义的所有内部资源的详尽列表。资源被定义为<组件>/<资源>。例如，cscc/GetConfigBlock 就是表达cscc组件中的资源GetConfigBlock。

策略

策略是fabric工作方式的基础，因为它们允许根据与完成请求所需资源相关联的策略来检查与请求关联的身份（或身份集合）。背书侧裂用于确定交易是否得到适当认可。通道配置中定义的策略被引用为修改策略以及访问控制，并在通道配置本身中定义。
策略类型分为：
* 签名策略
* ImplicitMeta 策略

签名策略

这些策略标识必须签署的特定用户才能满足策略。如：

Policies:
  MyPolicy:
    Type: Signature
    Rule: “Org1.Peer OR Org2.Peer”

样例中的策略构造可以解释为：命名为 MyPolicy的策略需要满足组织Org1或者Org2中的peer节点身份的签名。
签名策略支持”AND、OR、NOutOf”的任意组合，允许建立极其强大的规则，比如：组织A的管理员和另外两名管理员，或者20位组织管理员中的11位。

ImplicitMeta策略

ImplicitMeta策略聚合配置层次结构中更深层次的策略结果，这些策略最终由签名策略定义。它们支持默认规则，例如“大多数组织管理员”。与签名策略相比，这些策略使用不同但任然非常简单的语法：

Policies:
  AnotherPolicy:
    Type: ImplicitMeta
    Rule: "MAJORITY Admins"

这里，策略AnotherPolicy可以由“MAJORITY of Admins”满足，其中管理员最终由较低级别的签名策略制定。

访问控制在哪被指定

访问控制默认定义在configtx.yaml,configtxgen使用该文件构建通道配置。
访问控制升级有两种方法：
* 通过编辑configtx.yaml本身，可以将ACL修改传播到任何新通道
* 通过更新特定通道的通道配置中的访问控制来更新访问控制

如何在configtx.yaml中格式化ACL

ACL被格式化为键值对，由资源函数名称后跟字符串组成。这里有个configtx.yaml的例子
这里有两个样例：

#在peer节点提交链码的ACL策略
peer/Propose: /Channel/Application/Writers

# 发送区块事件的ACL策略
event/Block: /Channel/Application/Readers

这些ACL定义对”peer/Propose”和”event/Block”资源的访问限制为分别满足在规范路径”Channel/Application/Writers”和”/Channel/Application/Readers”中定义的策略的身份。

在configtx.yaml中更新ACL默认值

如果在引导网络时需要覆盖ACL默认值，或者在引导通道之前更改ACL，最佳做法是更新configtx.yaml。
假设你需要修改”peer/Propose”ACL默认值（在peer节点调用链码的特点策略），在路径”/Channel/Application/Writers”下名为MyPolicy的策略。
这是通过添加名为MyPolicy（这里只是个举例命名）的策略来完成的。该策略在configtx.yaml内的Application.Policies部分中定义，并指定要检查以授权或拒绝用户访问权限的规则。对于这个例子，我们将要创建一个标识SampleOrg.admin的签名策略。

Policies: &ApplicationDefaultPolicies
    Readers:
        Type: ImplicitMeta
        Rule: "ANY Readers"
    Writers:
        Type: ImplicitMeta
        Rule: "ANY Writers"
    Admins:
        Type: ImplicitMeta
        Rule: "MAJORITY Admins"
    MyPolicy:
        Type: Signature
        Rule: "OR('SampleOrg.admin')"

然后，在configtx.yaml文件中编辑Application:ACLs部分，编辑资源”peer/Propose”从
“peer/Propose: /Channel/Application/Writers”
修改为
“peer/Propose: /Channel/Application/MyPolicy”

在configtx.yaml中更改了这些字段后，configtxgen工具将使用创建通道创建事务时定义的策略和ACL。当联盟成员的一个管理员适当地签名和提交时，将创建具有已定义的ACL和策略的新通道。
一旦MyPolicy被引导到通道配置中，它也可以被引用以覆盖其他ACL默认值。比如：

SampleSingleMSPChannel:
    Consortium: SampleConsortium
    Application:
        <<: *ApplicationDefaults
        ACLs:
            <<: *ACLsDefault
            event/Block: /Channel/Application/MyPolicy

这将限制订阅区块事件到SampleOrg.admin的能力。
如果已创建了要使用此ACL的通道，则必须使用以下流程一次更新一个通道配置：

在通道配置中更新ACL默认值

如果已经创建了希望使用MyPolicy策略来限制访问资源”peer/Propose”的通道(或者如果他们想要创建ACL，他们不希望其他通道了解),他们必须通过配置更新事务一次更新一个通道配置。

注意：通道配置事务是一个我们不会再深入研究的过程。如果您想了解更多关于他们的信息，请查看关于通道配置更新的文档以及“向通道添加组织”的教程。

在提取，转换并剥离其元数据的配置块之后，您可以通过Application: policies下添加MyPolicy策略来编辑配置，其中Admins,Writers和Readers策略已经存在。

"MyPolicy": {
  "mod_policy": "Admins",
  "policy": {
    "type": 1,
    "value": {
      "identities": [
        {
          "principal": {
            "msp_identifier": "SampleOrg",
            "role": "ADMIN"
          },
          "principal_classification": "ROLE"
        }
      ],
      "rule": {
        "n_out_of": {
          "n": 1,
          "rules": [
            {
              "signed_by": 0
            }
          ]
        }
      },
      "version": 0
    }
  },
  "version": "0"
},

请特别注意这里的”msp_identifer”和”role”。
然后，在配置中的ACL部分，更改资源”peer/Propose”的ACL，从：

"peer/Propose": {
  "policy_ref": "/Channel/Application/Writers"

更改为：

"peer/Propose": {
  "policy_ref": "/Channel/Application/MyPolicy"

注意：如果您的通道配置中未定义ACL，则必须添加整个ACL结构。
配置更新后，需要通过常用通道更新流程提交。

满足需要访问多个资源的ACL

如果成员发出调用多个系统链码的请求，则必须满足这些系统链码的所有ACL。
例如，资源”peer/Propose”引用通道上的任何提议请求。如果特定的提案请求一个需要满足Writers权限的标识和一个满足MyPolicy权限的标识的两个系统链码，然后，提交提案的成员必须具有对Writers和MyPolicy权限评估为”true”的标识。
在默认配置中，Writers是一个规则为SampleOrg.member的签名策略。意识就是”组织中的任意成员”。上面提到的策略”MyPolicy”，具有”SampleOrg.admin”规则，意思就是”组织中的任意管理员用户”。为了满足这些ACL，成员必须是组织SampleOrg的管理员和成员。默认情况下，所有的管理员也是成员（虽然并非所有管理员都是成员），但是可以将这些策略重写为您想要的任何内容。因此，非常有必要跟踪这些策略，以确保无法满足peer节点提案的ACL(除非这是有意的)。

使用实验性ACL特性功能的客户的迁移注意事项

以前，访问控制列表的管理是在通道创建事务的isolated_data部分中完成的，并通过PEER_RESOURCE_UPDATE事务进行更新。起初，认为资源树将处理多个函数的更新，这些函数最终以其他方式处理，因此维护单独的并行peer节点配置树被认为是不必要的。
可以使用v1.1中的实验资源树进行客户迁移。由于官方v1.2版本不支持旧的ACL方法，因此fabric网络运营方需要关闭所有的peer节点。然后，他们应该将peer节点升级到v1.2，提交一个通道重新配置事务，该事务启用v1.2功能并设置所需的ACL，然后最终重新启动升级的peer节点。重新启动的peer节点将立即使用新的通道配置并根据需要强制执行ACL。