Hyperledger fabric Hyperledger Composer：在多组织结构中创建参与者

我在Fabric网络上实现了三种组织结构。还有一个单独的订购者。比如说Org1，Org2，Org3和订购者。Org1、Org2和Org3有自己的CA并使用CouchDB。所有对等节点都连接到同一个通道

这是一个贸易网络，每个组织代表一家贸易公司。为了进行操作，他们创建自己的参与者在网络中进行交易

每个组织有两个用户将为其公司进行交易

我正在使用Composer REST服务器访问网络。因此，这些组织中的每一个都有一个业务网络管理员，他们可以通过该管理员在网络上创建参与者/用户

要启动REST服务器，假设我使用Org1的商务网卡

我如何确保，如果Org1正在创建任何参与者，它只映射到Org1的公司？我怎样才能限制Org1为Org2创建参与者，因为我发现这个REST服务器是使用Org1的卡设置的？我可以使用Composer的permissions.acl文件管理此文件吗

有没有办法在运行时获取调用网络管理员的身份来管理它

---

我在什么地方缺少研究吗？任何参考/指导都会有帮助。

假设每个组织有三个不同的管理员参与者，他们负责为各自的组织创建用户（参与者）。在这里，您可以使用ACL，这样一个组织的管理员就不会创建另一个组织的用户。现在，第二件事是您需要在多用户模式下启动composer rest服务器。为此，您需要将所有网卡存储在一个位置，然后使用身份验证机制（即passport策略）访问特定的网卡。您可以参考多用户模式编写器示例，它在编写器教程中。虽然在这种情况下，您也需要用一张卡启动rest服务器，但这只是为了读取网络，只是为了生成rest api，而不是进行任何事务。

添加到上面@user9040429的注释中：

1） 访问控制列表（规则）：控制哪些业务网络管理员（在“交易网络”中）：例如，见下文：

组织

是建模参与者中的一个字段/属性。这是“更好的做法”，而不是试图在业务网络之外“派生”他/她的组织（您的交易输入将允许对参与者进行检查，从中可以导出“他/她的”组织）

其中，DENY是Composer ACL规则中的隐式默认值，即除非明确允许-还请注意，早期规则中的“匹配”（您可以有许多规则，尤其是当它们针对相同的资源时）将意味着它可能无法到达该规则进行评估（因为它从上到下读取规则）-只是说

2） 上述规则应足以满足您的ACL需求。但只需说明，在您的事务逻辑（如果您需要访问它）中，您可以使用以下功能，如文档中本页所示->-请参阅代码示例：

getcurrentParticipant（）

//当前业务网络参与者

---

getcurrentIdentity（）< /代码> //标识，由布料发布，映射到上述参与者
，因此在资源中添加组织属性似乎是更好的选择。但是，如果我们有三个组织的三个网络管理员，他们都将有机会更新和部署BNA文件。最坏的情况是，如果我们考虑一个如果组织管理员更新ACL文件并部署bna文件，我们是否有暴露数据的风险？您可以（如果您愿意）按照所述控制业务网络的
网络
控制域，并再次设定一个条件，仅允许org1（例如）访问网络操作（仅），假设您的合作伙伴组织同意。所谓“部署”，实际上是指“升级能力”或“修改能力”，因为业务网络已经部署到每个组织的对等方。类似地（如果我在后一个问题上理解正确的话），您可以“锁定”业务网络中“其他组织管理员”可以做的事情（防止业务网络本身的“数据风险”）.明白了。如果三个组织在同一个渠道上，那么创建三个不同的组织有意义吗？或者让这三个实体成为单个组织的一部分会更好？我实际上对这个不同的组织部分感到困惑。我认为创建三个组织更好，如果所有三个组织都有能力创建和管理区块链基础设施。
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
}