通过前面几周的学习，我们已经知道Fabric跟其他区块链项目的差别在于：私密且有授权。在本周的周记中，我们将探讨一下其内部的授权机制。
所谓的有授权其实是两层含义：
- 允许参与Fabric环境
- 允许参与业务网络的交易
参与Fabric环境
与“任何数据库应用要与数据库交互首先需要有数据库服务器账户”类似，任何Fabric应用都必须要得到授权允许访问Fabric环境。但是，与简单的数据库应用不一样的是，仅仅只有应用本身并不足以形成业务交易。这还涉及到Fabric环境中的其他两个重要角色：
- 保存账本的Peer
- 负责打包的Orderer
只有Client（应用）、Peer和Orderer都得到了授权，才算是把整个环境盘活。
这一步的授权体现为其各自的CA证书，对此Fabric提供了相应的基础支撑：Fabric-CA服务器。由于Fabric的环境并不是由一家组织全权管理，因此这些证书并不一定是由一家组织签发的。
但不管怎么说，只要记住：证书是参与Fabric的前提条件。
参与业务网络的交易
还是拿前面的数据库应用来做类比：拥有数据库账户并不意味着应用就能为所欲为，想访问哪些表就访问哪些表。拥有账户只意味着能够建立起数据库连接，但是否可以对相关表进行操作，还得看这个账户是否得到了相应的授权。
对于Fabric中的各个参与者（Client、Peer和Orderer）来讲，道理也是一样的。拥有证书只是拿到了进入Fabric大门的通行证，但是否能参与交易，则要看对应的授权。这个授权则体现为MPS。
“CA和MPS的分离”可视为“身份和授权的分离”，即为：Authentication和Authorization的关系。
MPS的级别
在现实世界中，分级授权非常常见，这一点也适合Fabric。在Fabric中，MPS级别分为：
- Network MPS，定义网络成员以及网络管理员，管理员有权完成某些管理任务，如创建Channel。
- Channel MPS，定义Channel成员以及Channel管理员。
- Local MPS，服务于client和node，对于node又细分为：
- Peer MPS
- Orderer MPS
注意：对于每个node和client，必需定义Local MPS。
Composer中的权限
在前面的文章中，我们已经看到Composer对于简化Fabric开发的作用。但如果要用好它，必需理解其权限相关的内容。
Composer中权限有关的概念分为：
- Participant，它是逻辑上的实体，在Model文件（.cto）中定义。
- Identity，身份标识，执行“composer identity issue”时，Composer会调用Fabric的CA签发新证书。
- 注意：调用issue命令的前提是已经有Participant。
- Card，即business card，其中包含有connection和ca相关的信息。“composer identity issue”执行过程中会用到，基于用到的Card，该命令产生新的.card文件。
得到Card之后，需要将其导入到Fabric中才能使用。这一步非常关键，因为安装我们开发出来的Business Network（.bna）必需要用到它。
讲到这里，就有必要讲讲Composer的两级管理员：Hyperledger Fabric administrator（即Peer Admin）和Business network administrator（即 Network Admin）。两者的区别在于：
- 前者可以安装Business Network和管理后者。
- 后者可以更新网络、查看各个注册对象，以及管理网络的Participant。
缺省情况下，在启动网络（“composer network start”）时，Composer会自动创建一个Business network administrator。
在业务权限控制方面，Composer比Fabric往前迈了一大步，毕竟前者主要是为开发者服务，而后者只是基础设施。Composer内部提供了细粒度的业务相关的权限控制机制：ACL，它在Fabric中找不到对应物。ACL通过规则的形式定义了：participant对assert（resource）的操作规则，只有满足条件的操作才被接受。在其参考文档中，大家可以了解其使用和语法。
总结
至此，Fabric权限相关的知识点基本已经点出和梳理：
- 证书是门票，但要参与业务还需MPS。
- Composer应用（Business Network）必需至少有一个Participant，它要关联到Identity，并最终以Card体现。
- Composer的ACL是业务权限框架，并不属于Fabric权限架构的范畴。
网友评论