Hyperledger Composer: Creating participants in a multi org fabric

Question

I have implemented three org structure on the Fabric network. And a solo orderer. Let's say Org1, Org2, Org3 and the Orderer. Org1, Org2, and Org3 have their own CA and uses CouchDB. All the peer nodes are connected to the same channel.

This is a trade network where each organization represents a trading company. And to operate they create their own participants to transact in the network.

There are two users per organization who'll be carrying out trades for their company.

I'm using Composer REST server to access the network. Thus, each of these organizations has a business network admin through which they can create participants/users on the network.

To start the REST server, say I use business network card of Org1.

1. How do I make sure that if Org1 is creating any participant, it gets mapped to Org1's company only? And how can I restrict Org1 from creating participant for Org2, sighting that this REST server is setup using Org1's card? Can I manage this using Composer's permissions.acl file?
2. Is there a way to get the invoking network admin's identity at the runtime to manage this?

Am I lacking research somewhere? Any refrences/guidance will be helpful.

Answer 1

Adding to the comments from @user9040429 above:

1) Access Control Lists (Rules): to control what business network admins (in 'trade-network': Eg see below: organization is a field/attribute in your modeled participant. This is 'better practice' rather than trying to 'derive' his/her org, outside of the business network (your transaction input would allow a check on the participant, from which 'his/her' org can be derived)

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
}

and where DENY is implicit default in the Composer ACL rules ie unless explicitly ALLOWed - note also that a 'match' in an earlier rule (you could have many rules, especially if they target the same resources) will mean it might not reach this rule to evaluate (as it reads the rules top to bottom) - just saying.

2) The rule above should be sufficient for your ACL needs. But just to say that in your transaction logic (if you need to access it) you can use the following functions as shown in this page in the docs -> https://hyperledger.github.io/composer/latest/business-network/programmatic-access-control - see the code samples:

getcurrentParticipant() // current business network participant

getcurrentIdentity() // the identity, issues by Fabric, that's mapped to the above participant

Answer 2

Lets say you have three different admin participants for each org, who are responsible for creating users(participants) for their respective orgs. Here you can use acls so that admin of an org doesn't create a user of another org. Now second thing is you need to start composer rest server in multiuser mode. For that you need to store all the network cards at one place and then use an authentication mechanism i.e. passport strategy to access a particular card. You can refer to multiuser mode composer example, its there in composer tutorial. Though in this case also you need to start the rest server with a card but thats just to read the network , just to generate the rest api and not to do any transaction.