Explanation on configtx.yaml details

hanesoliveira · May 2019

Hi guys!

I am trying to make a right relation between theory and the approach Hyperledger Fabric took for configurations, etc.

In the official sample for configtx.yaml, we can see this structure on the section "Organizations":

Organizations:
- &SampleOrg
Name: SampleOrg
ID: SampleOrg
MSPDir: msp

We have also this explanation for the "MSPDir":

"MSPDir is the filesystem path which contains the MSP configuration."

For whom is this configuration (MSP path)? The admin of the company?

In the example of the course the MSPDir points to an MSP having the root CA and the admin.

Let me explain my question. When we create identities on a certain CA we are identifying nodes, users or whoever (machines or people) will have access to the network. Therefore, the identity should be related to some player of the network. Company is a more broad and abstract concept. So, who will use the identity to personify the organization? The admin identity is the representation of a company?

Thanks!

akoita · May 2019

Hi hanesoliveira,

Interesting question, I will try to answer it according to my understanding.

First, I would like to emphasize that this is indeed the MSP config of the channel: https://hyperledger-fabric.readthedocs.io/en/release-1.4/msp.html#channel-msp-setup

It's sure that the admin is a special identity in the organization, and so in the Fabric channel network configuration. Fabric must know the identity of the admin to allow him to perform admin operations.

But the admin will not be obviously the only identity to operate on the network, the peers nodes and the users must be authorized too, for others operations. And Instead of putting the identities of all others users in the channel MSP, we put just the CA of their identities.

And Fabric even allows to classify identities as “peers” or “clients”: https://hyperledger-fabric.readthedocs.io/en/release-1.4/msp.html#identity-classification.

It would be more interesting to look at the content of a channel config in JSON format. Below, I extracted just the MSP section for the Org1 in an example of channel config. In this JSON, we can see:

the admin certificate
the “fabric_node_ous” certificates, that classify identities as “peers” or “clients”.
the root certificate
the TLS root certificate.

"value": {
    "config": {
        "admins": [
            "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNRRENDQWVlZ0F3SUJBZ0lSQU15SDdjYWJVT003RlBPSFBGbTArZEV3Q2dZSUtvWkl6ajBFQXdJd2dZRXgKQ3pBSkJnTlZCQVlUQWxWVE1STXdFUVlEVlFRSUV3cERZV3hwWm05eWJtbGhNUll3RkFZRFZRUUhFdzFUWVc0ZwpSbkpoYm1OcGMyTnZNU0F3SGdZRFZRUUtFeGR2Y21jeExtRmliM1ZpWVd0aGNtdHZhWFJoTG1OdmJURWpNQ0VHCkExVUVBeE1hWTJFdWIzSm5NUzVoWW05MVltRnJZWEpyYjJsMFlTNWpiMjB3SGhjTk1UZ3hNakUyTVRNME9UQXcKV2hjTk1qZ3hNakV6TVRNME9UQXdXakJ6TVFzd0NRWURWUVFHRXdKVlV6RVRNQkVHQTFVRUNCTUtRMkZzYVdadgpjbTVwWVRFV01CUUdBMVVFQnhNTlUyRnVJRVp5WVc1amFYTmpiekVQTUEwR0ExVUVDeE1HWTJ4cFpXNTBNU1l3CkpBWURWUVFEREIxQlpHMXBia0J2Y21jeExtRmliM1ZpWVd0aGNtdHZhWFJoTG1OdmJUQlpNQk1HQnlxR1NNNDkKQWdFR0NDcUdTTTQ5QXdFSEEwSUFCR3l6bzAvRXY4ZTd2N3RjVEFXOWEzaWdLM3pjb00xMzBlcXNVMW8xT05KKworNUY1ZURDRkt6Um5xdjVVM0RWbE9ZbWpWOXlNeTE3Z0NENjE3a0NsUFIralRUQkxNQTRHQTFVZER3RUIvd1FFCkF3SUhnREFNQmdOVkhSTUJBZjhFQWpBQU1Dc0dBMVVkSXdRa01DS0FJRDVqRXpVQ1lTTEJUcEFSSEt6QkxpaTMKcng2QXEzMnZyT0JydEdqSnJyNC9NQW9HQ0NxR1NNNDlCQU1DQTBjQU1FUUNJRGI0ZnBydWNidzUzUmxaRU9JcQpjdm15emJSaTdsT2NrYmpZMEU4SWhMaU1BaUJmZjNnL043dnFQZHo1cU5EYm9CWVAzZ1dnQXpPOGhHeXBIblkzClpDclFldz09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K"
        ],
        "crypto_config": {
            "identity_identifier_hash_function": "SHA256",
            "signature_hash_family": "SHA2"
        },
        "fabric_node_ous": {
            "client_ou_identifier": {
                "certificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNZRENDQWdlZ0F3SUJBZ0lRTGt4aEZUTXFuc1pvWm84a21GUkdCREFLQmdncWhrak9QUVFEQWpDQmdURUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhJREFlQmdOVkJBb1RGMjl5WnpFdVlXSnZkV0poYTJGeWEyOXBkR0V1WTI5dE1TTXdJUVlEClZRUURFeHBqWVM1dmNtY3hMbUZpYjNWaVlXdGhjbXR2YVhSaExtTnZiVEFlRncweE9ERXlNVFl4TXpRNU1EQmEKRncweU9ERXlNVE14TXpRNU1EQmFNSUdCTVFzd0NRWURWUVFHRXdKVlV6RVRNQkVHQTFVRUNCTUtRMkZzYVdadgpjbTVwWVRFV01CUUdBMVVFQnhNTlUyRnVJRVp5WVc1amFYTmpiekVnTUI0R0ExVUVDaE1YYjNKbk1TNWhZbTkxClltRnJZWEpyYjJsMFlTNWpiMjB4SXpBaEJnTlZCQU1UR21OaExtOXlaekV1WVdKdmRXSmhhMkZ5YTI5cGRHRXUKWTI5dE1Ga3dFd1lIS29aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRXJoTTRSOEJ5bXVvZXZlRXdHOW9HWU1KZwpkRjYyTDdUYTREL2JmZ01YYTVYOWRjMWRweVQzdkhrQkczblhJQ2tWU3FCL3F1eGFRNnQ1MFhjSGNUY2g3cU5mCk1GMHdEZ1lEVlIwUEFRSC9CQVFEQWdHbU1BOEdBMVVkSlFRSU1BWUdCRlVkSlFBd0R3WURWUjBUQVFIL0JBVXcKQXdFQi96QXBCZ05WSFE0RUlnUWdQbU1UTlFKaElzRk9rQkVjck1FdUtMZXZIb0NyZmErczRHdTBhTW11dmo4dwpDZ1lJS29aSXpqMEVBd0lEUndBd1JBSWdOY1VWSHhHZWUva2RMRzM2N045dHI1d0pBd1VOZDJuREFLOEw1cFNMCm05Y0NJRjdaVzJ3YXZTNndPb2JMVHZvZmc1Q2o4M0hSSVI3S3ZFK0JqZ2JyU3UwWAotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==",
                "organizational_unit_identifier": "client"
            },
            "enable": true,
            "peer_ou_identifier": {
                "certificate": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNZRENDQWdlZ0F3SUJBZ0lRTGt4aEZUTXFuc1pvWm84a21GUkdCREFLQmdncWhrak9QUVFEQWpDQmdURUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhJREFlQmdOVkJBb1RGMjl5WnpFdVlXSnZkV0poYTJGeWEyOXBkR0V1WTI5dE1TTXdJUVlEClZRUURFeHBqWVM1dmNtY3hMbUZpYjNWaVlXdGhjbXR2YVhSaExtTnZiVEFlRncweE9ERXlNVFl4TXpRNU1EQmEKRncweU9ERXlNVE14TXpRNU1EQmFNSUdCTVFzd0NRWURWUVFHRXdKVlV6RVRNQkVHQTFVRUNCTUtRMkZzYVdadgpjbTVwWVRFV01CUUdBMVVFQnhNTlUyRnVJRVp5WVc1amFYTmpiekVnTUI0R0ExVUVDaE1YYjNKbk1TNWhZbTkxClltRnJZWEpyYjJsMFlTNWpiMjB4SXpBaEJnTlZCQU1UR21OaExtOXlaekV1WVdKdmRXSmhhMkZ5YTI5cGRHRXUKWTI5dE1Ga3dFd1lIS29aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRXJoTTRSOEJ5bXVvZXZlRXdHOW9HWU1KZwpkRjYyTDdUYTREL2JmZ01YYTVYOWRjMWRweVQzdkhrQkczblhJQ2tWU3FCL3F1eGFRNnQ1MFhjSGNUY2g3cU5mCk1GMHdEZ1lEVlIwUEFRSC9CQVFEQWdHbU1BOEdBMVVkSlFRSU1BWUdCRlVkSlFBd0R3WURWUjBUQVFIL0JBVXcKQXdFQi96QXBCZ05WSFE0RUlnUWdQbU1UTlFKaElzRk9rQkVjck1FdUtMZXZIb0NyZmErczRHdTBhTW11dmo4dwpDZ1lJS29aSXpqMEVBd0lEUndBd1JBSWdOY1VWSHhHZWUva2RMRzM2N045dHI1d0pBd1VOZDJuREFLOEw1cFNMCm05Y0NJRjdaVzJ3YXZTNndPb2JMVHZvZmc1Q2o4M0hSSVI3S3ZFK0JqZ2JyU3UwWAotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==",
                "organizational_unit_identifier": "peer"
            }
        },
        "intermediate_certs": [],
        "name": "Org1MSP",
        "organizational_unit_identifiers": [],
        "revocation_list": [],
        "root_certs": [
            "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNZRENDQWdlZ0F3SUJBZ0lRTGt4aEZUTXFuc1pvWm84a21GUkdCREFLQmdncWhrak9QUVFEQWpDQmdURUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhJREFlQmdOVkJBb1RGMjl5WnpFdVlXSnZkV0poYTJGeWEyOXBkR0V1WTI5dE1TTXdJUVlEClZRUURFeHBqWVM1dmNtY3hMbUZpYjNWaVlXdGhjbXR2YVhSaExtTnZiVEFlRncweE9ERXlNVFl4TXpRNU1EQmEKRncweU9ERXlNVE14TXpRNU1EQmFNSUdCTVFzd0NRWURWUVFHRXdKVlV6RVRNQkVHQTFVRUNCTUtRMkZzYVdadgpjbTVwWVRFV01CUUdBMVVFQnhNTlUyRnVJRVp5WVc1amFYTmpiekVnTUI0R0ExVUVDaE1YYjNKbk1TNWhZbTkxClltRnJZWEpyYjJsMFlTNWpiMjB4SXpBaEJnTlZCQU1UR21OaExtOXlaekV1WVdKdmRXSmhhMkZ5YTI5cGRHRXUKWTI5dE1Ga3dFd1lIS29aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRXJoTTRSOEJ5bXVvZXZlRXdHOW9HWU1KZwpkRjYyTDdUYTREL2JmZ01YYTVYOWRjMWRweVQzdkhrQkczblhJQ2tWU3FCL3F1eGFRNnQ1MFhjSGNUY2g3cU5mCk1GMHdEZ1lEVlIwUEFRSC9CQVFEQWdHbU1BOEdBMVVkSlFRSU1BWUdCRlVkSlFBd0R3WURWUjBUQVFIL0JBVXcKQXdFQi96QXBCZ05WSFE0RUlnUWdQbU1UTlFKaElzRk9rQkVjck1FdUtMZXZIb0NyZmErczRHdTBhTW11dmo4dwpDZ1lJS29aSXpqMEVBd0lEUndBd1JBSWdOY1VWSHhHZWUva2RMRzM2N045dHI1d0pBd1VOZDJuREFLOEw1cFNMCm05Y0NJRjdaVzJ3YXZTNndPb2JMVHZvZmc1Q2o4M0hSSVI3S3ZFK0JqZ2JyU3UwWAotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg=="
        ],
        "signing_identity": null,
        "tls_intermediate_certs": [],
        "tls_root_certs": [
            "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNaekNDQWcyZ0F3SUJBZ0lRSGkyWngzbTNMRk1uR3lqUmorV0MrREFLQmdncWhrak9QUVFEQWpDQmhERUwKTUFrR0ExVUVCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtYjNKdWFXRXhGakFVQmdOVkJBY1REVk5oYmlCRwpjbUZ1WTJselkyOHhJREFlQmdOVkJBb1RGMjl5WnpFdVlXSnZkV0poYTJGeWEyOXBkR0V1WTI5dE1TWXdKQVlEClZRUURFeDEwYkhOallTNXZjbWN4TG1GaWIzVmlZV3RoY210dmFYUmhMbU52YlRBZUZ3MHhPREV5TVRZeE16UTUKTURCYUZ3MHlPREV5TVRNeE16UTVNREJhTUlHRU1Rc3dDUVlEVlFRR0V3SlZVekVUTUJFR0ExVUVDQk1LUTJGcwphV1p2Y201cFlURVdNQlFHQTFVRUJ4TU5VMkZ1SUVaeVlXNWphWE5qYnpFZ01CNEdBMVVFQ2hNWGIzSm5NUzVoClltOTFZbUZyWVhKcmIybDBZUzVqYjIweEpqQWtCZ05WQkFNVEhYUnNjMk5oTG05eVp6RXVZV0p2ZFdKaGEyRnkKYTI5cGRHRXVZMjl0TUZrd0V3WUhLb1pJemowQ0FRWUlLb1pJemowREFRY0RRZ0FFb3I0UjQ0YWM0MUl0R055dgpYU0xhTVJCUFFiMms3UmNTc0RCL000UEdOTGRwWE1acVVNNTkybTlieW04RmRmTkZiQkNSamhCQTFFRlVHU3k5CkFlT0ltcU5mTUYwd0RnWURWUjBQQVFIL0JBUURBZ0dtTUE4R0ExVWRKUVFJTUFZR0JGVWRKUUF3RHdZRFZSMFQKQVFIL0JBVXdBd0VCL3pBcEJnTlZIUTRFSWdRZzZ6cXEzMFJGTG1SMHd0cmZGMkJjNENPemh5Q1NVcjJ2dUtFVAozSU1UN3I0d0NnWUlLb1pJemowRUF3SURTQUF3UlFJaEFNL2JRaGxjSTZmTWhEWlloTGE3aE9nYjJGaGx5RzBRCnU3blpkWkJ2bmEyTUFpQmJnTmpha0QzUDF3Z2RIK1ZudWxsMUxBdWJnS2JoTDNhOXh6RU12d1pzbHc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg=="
        ]
    },
    "type": 0
},

kmyatt · May 2019

To @hanesoliveira,

Comments are inline.

Q.) For whom is this configuration (MSP path)? The admin of the company?_**

A.) MSP is at Organization level, not for a specific peer.

Q.) Let me explain my question. When we create identities on a certain CA we are identifying nodes, users or whoever (machines or people) will have access to the network. Therefore, the identity should be related to some player of the network. Company is a more broad and abstract concept. So, who will use the identity to personify the organization? The admin identity is the representation of a company?

A.) I'm still not sure if Im necessarily following your question, but let me explain...Certificate Authorities create, issue, and manage certificates for personal identification of a peer or orderer. The MSP is (once again) an organization level identifier responsible for identifying which certificates are able to do what, be apart of the organization, etc. For example, one role of MSP's can be that it is responsible for identifying which cert is an admin of the organization. But the actual certificate inside of that specific area of the msp dir represents the actual peer.

I would also suggest you check out the key concepts section of the Fabric Docs to learn more about MSP, as it can also help your understanding.
https://hyperledger-fabric.readthedocs.io/en/release-1.4/key_concepts.html

hanesoliveira · May 2019

Thanks for the feedback @akoita I'll take a careful look!

To @kmyatt:

Thanks for going on every key point. But I'll try to simplify my question and by the way I think this is a very valuable discussion. I've read the whole material of Fabric already before this course and I got back there many times to check the idea of the MSP, CA, etc. What I understood is this:

We have channel and local MSPs.
Every node/machine in the network will have its own MSP structure (local MSP), where along with other directories and files, will have its CA certificate (msp/cacerts), certificates for admins (msp/admincerts) that will access that node and certificates for signing transactions (msp/signcerts) that represent the node's identity on the CA.

With that in mind and to better understand how to define companies and the genesis block, I created another project.

1) I created from scratch an image of the CA, defining directories, binary files, etc. I redefined the self-signed certificate putting another structure for the organizations (not the default org1 and org2), so that I could make the right affiliations later on.

affiliations:
company-a:
- dept
company-b:
- dept
company-c:
- dept

2) I started to create one by one of the cryptographic material for peers, administrators and orderer, making the right affiliation under those companies defined inside the CA. In this structure company-a is the orderer company and will have an orderer and an administrator.

Directories with crypto material in my computer:

/fabric-ca-client
/company-a
/admin
/orderer
/company-b
/admin
/peer
/company-c
/admin
/peer

3) I created from scratch an image of the orderer, redefining everything as well.

4) Lastly I populated the configtx.yaml with values that were related to the MSP companies. Inside configtx.yaml we need to define organizations in order to reference them in other parts of the same config file:

Organizations:
- &company-a
Name: company-a
ID: company-a
MSPDir: /Users/hanesoliveira/Workspace/hyperledger/fabric-ca-client/company-a/admin/msp

So I pointed MSPDir to a MSP in my filesystem containing just the /admincerts and /cacerts directories with the related certificates. I could only create the genesis block when I pointed to a MSP that had the related admin certificate in /admincerts. The admin is registered under certain company by the CA. Therefore I think that the system is checking that affiliation to define the org.

So, I was curious to understand: what the system is taking into consideration (certificate, MSP structure, whatever) to define the organization in this part of configtx.yaml?

Hopefully I could be less confusing, but if not so let me know. My goal is to nail this properly.

Thanks!

hanesoliveira · May 2019

Hi @kmyatt, thanks for answering. I'll prepare again an answer to continue the discussion, because I already lost two answers on this forum after editing. I am writing it now again.

hanesoliveira · May 2019

Hi @kmyatt!

Thanks for carefully answering my points. This subject is very important and can cause confusion, so I appreciate your help.

I have read the whole official material before taking the course, but I feel that every tutorial or course take just a glance over the initial definitions of the genesis block and establishment of companies by the CA and further relation with the configtx.yaml. So I'll share the background for the question. Sorry if it takes too long.

We know that we have local and channel MSPs. Therefore we'll have, at least for nodes, peers, etc, a local structure of the MSP. There we have the, along with other things, the CA certificate, certificates for admins of that node and its own certificate to sign transactions. The channel MSP, on the other hand, will be defined for the channel and everybody that have the rights will have a copy of that.

So, in order to understand better the intricate relationships of MSPs I started a parallel project. My actions:

1) I created a Docker image from scratch, based on Ubuntu and started to organize the CA step by step. At the end, I recreated the definitions for companies at the fabric-ca-server-config.yaml and generated the self-signed certificate. The structure for organizations follows:

affiliations:
company-a:
- dept
company-b:
- dept
company-c:
- dept

2) I generated the whole crypto material directly with the CA. Then I could register and enroll the peers, admins and so forth. The "company-a" was chosen to be the orderer company. The structure of directories for the crypto material:

../fabric-ca-client
/company-a
/admin
/orderer
/company-b
/admin
/peer
/company-c
/admin
/peer

3) Then, I filled the configtx.yaml with the definition used in the CA affiliations and pointed MSPDir to the respective directory for the admin of company-a. Every company was defined as well.

Organizations:
- &company-a
Name: company-a
ID: company-a
MSPDir: ../fabric-ca-client/company-a/admin/msp

Finally, I could generate the genesis block. This admin MSP for company-a has the CA certificate (cacerts) and the admin certificate (admincerts). So, at this point I am wondering:

Does the system check if the ID described in configtx.yaml (organizations) match the definition contained into the CA section (affiliations) to define the company? Is this the verification to create the MSP channel?

hanesoliveira · June 2019