我已经在Fabric网络上实现了三个组织结构。和一个单独的订购者。假设Org1,Org2,Org3和订购者。 Org1,Org2和Org3拥有自己的CA,并使用CouchDB。所有对等节点都连接到同一通道。
这是一个贸易网络,每个组织都代表一个贸易公司。为了运作,他们创建了自己的参与者以在网络中进行交易。
每个组织有两个用户将为其公司进行交易。
我正在使用Composer REST服务器访问网络。因此,这些组织中的每一个都有一个业务网络管理员,通过他们可以在网络上创建参与者/用户。
要启动REST服务器,请说我使用Org1的名片。
我在某处缺乏研究吗?任何参考/指导都会有所帮助。
答案 0 :(得分:1)
让我们说您对于每个组织都有三个不同的管理员参与者,他们负责为各自组织创建用户(参与者)。在这里您可以使用ACL,这样一个组织的管理员就不会创建另一个组织的用户。现在第二件事是您需要以多用户模式启动composer rest服务器。为此,您需要将所有网卡存储在一个位置,然后使用身份验证机制,即通行证策略来访问特定的卡。您可以在composer教程中参考多用户模式作曲家示例。尽管在这种情况下,您也需要使用卡来启动其余服务器,但这仅是为了读取网络,只是生成其余api,而不执行任何事务。
答案 1 :(得分:1)
在上述@ user9040429中添加评论:
1)访问控制列表(规则):控制哪些业务网络管理员(在“交易网络”中:例如,参见下文:organization
是您的建模参与者的字段/属性。这是“更好的做法”而不是尝试在业务网络外部“推导”他/她的组织(您的交易输入将允许对参与者进行检查,从中可以得出“他/她”的组织)
rule CreateParticipantsbyOrg {
description: "example"
participant(t): "org.hyperledger.composer.system.NetworkAdmin"
operation: ALL // (CREATE, READ, UPDATE, DELETE)
resource(r): "mybiz.domain.Traders"
condition: (t.getIdentifier() == r.organization)
action: ALLOW
}
,并且在Composer ACL规则中DENY是隐式默认值,即除非明确允许-还要注意,较早规则中的“匹配项”(您可能有很多规则,特别是如果它们针对相同的资源)将意味着它可能不会达到要评估的规则(从上到下读取规则)-只是说。
2)上面的规则应足以满足您的ACL需求。只是说,在事务逻辑中(如果需要访问它),可以使用文档中此页面中所示的以下功能-> https://hyperledger.github.io/composer/latest/business-network/programmatic-access-control-请参见代码示例:
getcurrentParticipant()
//当前的商业网络参与者
getcurrentIdentity()
//身份,由Fabric发布,并映射到上述参与者