What role am I operating from in the logic.js file composer? If I've defined permissions.acl such that two certain types of participant don't have any access to each other, may I still be able to, in my transaction handler (where both participants are involved by reference in the transaction body) inside logic.js, read/write any party's member variables arbitrarily?
Perhaps in other words, how is the "currentParticipant" determined by a transaction? Say I'm using the following started code for my app https://github.com/IBM/customer-loyalty-program/blob/master/web-app/app.js
The transactions are called by the nodejs runtime and not by a specific participant as far as I understand...
To interact with a hyperledger fabric network you will do as using an identity (certificate + private key). The composer runtime in the chaincode accesses that identity and then looks for the participant that it is mapped to. All identities must be mapped to a participant or you get a message saying the <common name> with identifier <unique id for the cert> has not been registered
Commands like composer network start, composer identity issue will bind an identity to a participant for you.
composer identity bind takes an existing identity and binds it to an existing participant.
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 would like to know how either Fabric or composer can enforce Access Control Logic (ACL). As I read through the documents, ACL is a way to control permission to peers within a channel. When I, as a peer, have a local copy of the ledger, what would prevent me from reading the data that I locally have, although in ACL I am denied to have access? In this case I am talking only about ACL without using the new feature private data collections.
I appreciate any help.
Thank you very much.
Nothing can prevent you from reading the data that you have locally, if you have access to that data.
ACL enforcement in Hyperledger Fabric works via policy evaluation - an ACL is just a policy, and for every action that a network node (peer or orderer) performs - it consults the policy to determine if the requester of the data is eligible according to the policy.
Note, that any data segregation mechanism may be not enough by its own, if the data may be obtained via other actions that have permissive policies. A good example for that is if you have a chaincode that checks that the client originates from a certain organization, but that client's certificate satisfies the "channel readers" policy - then the client can just request the block from the ordering service itself - and just compute the data that the client wants on its own after reading the data blocks.
Every peer can read from his local data but when it comes to data that is stored on ledger peers can't read that data without permission. Actually you as a peer only can access and store some part of ledger that is available not the whole of that.
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.