Multi server / multi org setup - cannot join org
nikolas-digitalBabylon opened this issue · comments
Hi,
I am trying to set the following up:
Server A - ordering org (ca + 3 ordering peers)
Server B - org1 (ca + 1 peer)
Server C - org2 (ca + 1 peer)
Server A spec.yaml:
`fabric:
cas:
- "ca.orderers.example.com"
orderers: - "orderer1.orderers.example.com"
- "orderer2.orderers.example.com"
- "orderer3.orderers.example.com"`
Server B spec.yaml:
`fabric:
cas:
- "ca.org0.example.com"
peers: - "peer1.org0.example.com"`
Server C spec.yaml:
`fabric:
cas:
- "ca.org1.example.com"
peers: - "peer1.org1.example.com"`
The scenario is that:
- ordering org is NOT controlled by either org0 or org1 operators
- org0 joins the network of ordering org
- org1 joins the network
- org0 creates channel and adds org1
How can I do that with minifabric ? In the examples provided, it is always assumed that orderers are at least under the control of the same operator, on same server. I would appreciate any hints.
But if I do that, it is assumed that the operator of server A, has the crypto material generated for org0 and org1, right? If yes, it is exactly what I want to avoid, the scenario is that they are separated organizations with different operators. Private keys should only be accessible to the operator of each org. Did I get something wrong?
Thank you!
@nikolas-digitalBabylon i guess if we operate the different organizations in different servers and make the other channel to join the main channel , it will not have the crypto material and the private keys of the other organization it will just change the channel configuration file and make the nodes to connect to each other , the private keys and all the other crypto keys will be available to that private network only , so one organization can do transaction on behalf of other organization , but they can query the committed block and see the transactions from other peers.
@nikolas-digitalBabylon You can follow the expand your network under docs in the repo to try so .
Hi,
thank you for your response. The point is the following: Normally, one org should not have the secret crypto material of other orgs. With this in mind, the flow should be:
- some operator sets up the ordering service (e.g. a service provider)
- org A is permitted to use the ordering service by the provider, so org A sends its public crypto material (the "join-request.json") to the orderer op, who ads them to the network / consortium.
- org B follows same way with org A, so they are both part of the consortium under the same ordering service. Now org A and org B can engage using the ordering service.
With the above, nobody shares his secret crypto material. This flow though, doesn't seem to be enabled by minifab. Am I missing something? Do maintainers see it otherwise? is another approach suggested?
Hi @nikolas-digitalBabylon , if you can see the steps in the expand network (docs folder github repo ) the join request is used is used in the Minifab before adding any organization to an existing network , and the endpoints.yaml (share the ordering service to new organization) , the main point of concern is the transactions and query to the ledger which is done using the private key which is only available to each user , no one has acess to that key , so without having access to these make is secure , i geuss .
I don'nt how much i followed up your query , @litong01 may answer it in better way !!!!!!!!