CODEWITHSUNDEEP
node.jsauthorizationhyperledger-fabrichyperledger-fabric-cahyperledger-chaincode
Ana Franco
Ana Franco

Reputation: 1801

Hyperledger Fabric how to manage authorization by mspid

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

Upvotes: 1

Views: 440

Answers (2)

hsnkhrmn
hsnkhrmn

Reputation: 980

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.

Upvotes: 1

Toddinpal
Toddinpal

Reputation: 345

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.

Upvotes: 0

Related Questions