通过前面几周的学习,我们已经知道Fabric跟其他区块链项目的差别在于:私密且有授权。在本周的周记中,我们将探讨一下其内部的授权机制。
所谓的有授权其实是两层含义:
与“任何数据库应用要与数据库交互首先需要有数据库服务器账户”类似,任何Fabric应用都必须要得到授权允许访问Fabric环境。但是,与简单的数据库应用不一样的是,仅仅只有应用本身并不足以形成业务交易。这还涉及到Fabric环境中的其他两个重要角色:
只有Client(应用)、Peer和Orderer都得到了授权,才算是把整个环境盘活。
这一步的授权体现为其各自的CA证书,对此Fabric提供了相应的基础支撑:Fabric-CA服务器。由于Fabric的环境并不是由一家组织全权管理,因此这些证书并不一定是由一家组织签发的。
但不管怎么说,只要记住:证书是参与Fabric的前提条件。
还是拿前面的数据库应用来做类比:拥有数据库账户并不意味着应用就能为所欲为,想访问哪些表就访问哪些表。拥有账户只意味着能够建立起数据库连接,但是否可以对相关表进行操作,还得看这个账户是否得到了相应的授权。
对于Fabric中的各个参与者(Client、Peer和Orderer)来讲,道理也是一样的。拥有证书只是拿到了进入Fabric大门的通行证,但是否能参与交易,则要看对应的授权。这个授权则体现为MSP。
“CA和MSP的分离”可视为“身份和授权的分离”,即为:Authentication和Authorization的关系。
在现实世界中,分级授权非常常见,这一点也适合Fabric。在Fabric中,MSP级别分为:
注意:对于每个node和client,必需定义Local MSP。
在前面的文章中,我们已经看到Composer对于简化Fabric开发的作用。但如果要用好它,必需理解其权限相关的内容。
Composer中权限有关的概念分为:
得到Card之后,需要将其导入到Fabric中才能使用。这一步非常关键,因为安装我们开发出来的Business Network(.bna)必需要用到它。
讲到这里,就有必要讲讲Composer的两级管理员:Hyperledger Fabric administrator(即Peer Admin)和Business network administrator(即 Network Admin)。两者的区别在于:
缺省情况下,在启动网络(“composer network start”)时,Composer会自动创建一个Business network administrator。
在业务权限控制方面,Composer比Fabric往前迈了一大步,毕竟前者主要是为开发者服务,而后者只是基础设施。Composer内部提供了细粒度的业务相关的权限控制机制:ACL,它在Fabric中找不到对应物。ACL通过规则的形式定义了:participant对assert(resource)的操作规则,只有满足条件的操作才被接受。在其参考文档中,大家可以了解其使用和语法。
至此,Fabric权限相关的知识点基本已经点出和梳理:
更多的区块链文章。
觉得有帮助的话,不妨考虑购买付费文章来支持我们 🙂 :
付费文章