In crypto-config.yaml for each organization we have Template and users, I know template number is the number of users but I can't understand what Users variable is used for
A template is used to refer to the number of peers that you want to have in an organization. Peers are the units which store the ledger. It is completely different from the type of users who update these ledgers. So maybe that is the difference between a template and user.
Related
I would like to use roles to identify what an organization can do in my hyperledger fabric blockchain, so, if org1 is an distributor it can call the contract1 and the contract2 but org2 that has an auditor role can only call contract2.
I am planning of doing it, by storing the msp roles in the blockchain and querying them in the contract to do the validation, and this roles can be stored in the blockchain on the instantiate method.
Something like this:
public async contract1(ctx: context) {
const cid = ctx.clientIdentity;
const role = await ctx.stub.getState(cid);
if (role === 'auditor') {
throw new Error('An Auditor can not issue a transference');
}
....
return response;
}
Is there a better way to associate a role to an mspid? Like directly on the certificate? But if the organization manages the CA, how can I warranty that they don't give themselves super powers and super roles? Or should I check directly on my code for each mspId?
Thanks
I am planning of doing it, by storing the msp roles in the blockchain
and querying them in the contract to do the validation, and this roles
can be stored in the blockchain on the instantiate method.
I think your approach is reasonable. It's open to changes and extensions later on.
Is there a better way to associate a role to an mspid? Like directly
on the certificate?
Embedding Attributes in Certs: As you mentioned, we cannot trust attributes on certificates on organization-wise roles. Our system knows about the root certificate of organizations, so only these can be our reference for such solution. Since client certificates are sighed with these root certificates, we can reach these certificate's issuer certificate as well. If we enforce organizations to put some attributes there, this would bring us a solution. This enforcement occurs during on-boarding time and validated manually by admins. Obviously this is a bad approach. Because it's static and we enforce some certificate actions for our custom solution, etc.
Here is a quick and dirty solution method I used before:
Embedding roles on MSP IDs: This is really a quick and dirty solution. i.e. MSP ID will be set as Org1_xyz where x, y and z are the different roles. You can easily get client's MSP ID and extract the organization's roles from here. It's a safe method since MSP ID is assigned to an organization by the admins during introducing the organization to the system channel. Afterwards it's not changeable at all and also this is information is very dependent on a chaincode logic, where MSP IDs are on higher level definition.
Relying on the contents of an enrollment certificate does indeed introduce a lot of trust on the CA issuing the cert. I know this is the idea behind attribute based access control (ABAC), and in some cases will work, but the trust issues are significant as any CA can issue a certificate with arbitrary "roles". I think the only real way to handle this is to maintain in chaincode a list of identities that you want to grant access to certain functions. Basically create your own access control lists that are maintained onchain.
We set up Hyperledger Fabric and added two channels (for two different applications). We also registered two users in our Organization (one for each application). We should restrict access to each channel so only the corresponding user can read and write based on affiliation or OU of the user.
We checked Hyperledger Fabric documentation on channel policies and did not find any indication on how to use OU or affiliation (i.e. conditions that go beyond "must be member of orgX").
From what I've read so far, I got the impression that restrictions within the organization can only be enforced in chaincode, but not by using policies (this is also indicated in this question).
Is this really the way to go? Is there no possibility to restrict access to either a OU or an attribute like affiliation by just using the channel policy?
You can define an MSP that is defined with the OU you have in mind, and then the user will have to belong to that MSP and use a certificate with that OU when it sends transactions.
I want to use Access control functionality in Fabric (like permission.acl in Hyperledger Composer), so how to achieve this in Fabric? and how to specify the user while accessing chaincode to test the Access controls provided for that user from node SDK.
eg:(like Tuna-network example in Composer) I want to give different CRUD access to chaincode functions to different participants/users.
There is no direct equivalent in hyperledger fabric for the Composer ACL functionality.
First you should look at access control lists in fabric to ensure that your fabric network has the correct level of security
https://hyperledger-fabric.readthedocs.io/en/release-1.3/access_control.html
(You would have to have done this anyway as even if you used composer ACLs to ensure a participant could not read something, if that pariticpant had the ability to query the ledger or is able to listen for block events they could still infer the data, unless encrypted, regardless of the Composer ACL denying read access).
The other fabric capability you could look at is what's termed "Attribute Based Access Control". This is where attributes with values are associated with a certificate and the fabric shims for each language provide a utility library to allow chaincode to extract those attribute values and then the chaincode implementation can make a decision on whether the identity making the request has the appropriate authority to perform whatever it has requested.
More details can be found here
https://hyperledger-fabric.readthedocs.io/en/release-1.3/chaincode4ade.html?highlight=client%20identity#chaincode-api
I have a scenario here, in which I want to register and enrol a user which can be used in multiple organisations. But I cannot get any way to do so. Does anyone have any way to achieve this.
I figured out how to solve my issue. I came across something called Organisational Units in the Fabric CA. We can have multiple intermediate CAs for multiple organisational units and one root CAs. Each Organisational Unit will act as an individual Org and the user registered and enrolled by root CA can access chaincodes in any of the Organisational Units.
I wanted to understand how are participants tied with Organization when we define the model.
For example if I have 3 participants(Grower, Shipper, Trader) and have a network of 3 organization(OrgGrower,OrgShipper, OrgTrader)
then will adding participants how is the one to one relationship mapped between Participants and Organization.
I want to do all this via Web site and give access to administrator for adding only there participants and but also want to
have a super admin which has access to all the organization. Is this achievable via Hyperledger composer
Answered same posting on Rocket Chat:
In Composer a Participant is just a data item, specifically an object in a Participant Registry. A Participant cannot access the Business Network on the Fabric until an Identity has been Issued to and bound to that Participant. Identities are generated by the CA which belongs to an Organisation. A user (administrator) with an Identity can create Participants if they have the ACL access to do so, but only an Identity with specific rights in the CA can issue Identities. This doc describes Participants and Identities in more detail: https://hyperledger.github.io/composer//managing/participantsandidentities
I don't know if CAs can 'cross certify' to allow your Super Admin to issue identities for the 3 CAs (Organizations). There is a #fabric-ca channel that should be able to answer that question.