Hyperledger Composer中基于组织的参与者身份发布限制 [英] Organization based restrictions for participant identity issuing in Hyperledger Composer

问题描述

让我们说我们有2个组织的网络(OrgA和OrgB)，两个组织都有自己的管理员"身份可以发布身份.如果OrgA的管理员身份为参与者"ParA"颁发身份，那么如何禁止OrgB为该参与者颁发身份?

lets say we have a 2 organization network (OrgA and OrgB) both organizations have there own "Admin" identity that can issue identities. If the admin identity for OrgA issues a identity for a participant "ParA", how can one prohibit OrgB to issue a identity for that participent?

推荐答案

您可以使用ACL来限制两个组织的管理员创建或可见的参与者的类型.最简单的方法是为每个单位指定参与者类别，并按类别控制对参与者的访问

You can use ACLs to restrict the kind of participants created or that are viewable, by either Organisation's admins. Simplest way is designated participant classes for each Org and control access to participants by class

或者，它们可以在同一参与者类中，但是具有标识的组织元数据.您必须坚持要求参与者是在同一参与者类中创建的.然后(使用适当的ACL)来自另一个组织"的组织管理员将无权将他发布的身份绑定到错误的"参与者(即，他甚至不应该看到，将其绑定到)，因为ACL中的条件检查将阻止访问.

Alternatively, they can be in the same participant class but have identifying Org metadata, ie. where you DO insist that the participants are created in the same participant class. Then (with ACLs in place) the org admin from 'another org' won't have the capability to bind an identity he issued, to the 'wrong' participant (ie one he should not even see, to bind it to), because a condition check in the ACL will prevent the access.

例如

rule myRule1 {
  description: "Org admin can see/access/create participants matching own org"
  participant(p): "org.acme.nwk.IssuerAdmins"  // ie only someone of this class, can 'issue identities' - 
  operation: ALL  // (CREATE, READ, UPDATE, DELETE) // do everything, for IDs in their Org ?
  resource(r): "org.acme.nwk.myParticipants"
  condition: (p.organisation == r.organisation) // can ONLY see or do anything with participants from own Org
  action: ALLOW
}

来自不同"组织的组织管理员-可以发布身份，但无法看到参与者不在他/她的组织中"(尝试映射到他自己的组织的身份).

An Org Admin from a 'different' org - can issue identities, but will not be able to see a participant 'not in his/her Org' (to try map to his own org's identities).

可能更简洁"并基于数据，但是如果要比较大量数据，则进行复杂的javascript评估(检查Org模式序列的属性值等)会增加更多开销. 您还可以采用另一种方法:

Its possible to be more 'succinct' and base it on data, but putting complex javascript evaluations (check the attribute value for an Org pattern sequence etc) adds more overhead, if large amounts of data is being compared against. you could also do another way:

这篇关于Hyperledger Composer中基于组织的参与者身份发布限制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！