When triggering a transaction with the "composer-cli" one has to specify the "enrollId" and the "secret" to be able to send the request. So transaction is fired in the context of a given fabric-user.
I was asking myself if there is a way to map the identity of the fabric-user firing the transaction to a given "participant" from the Participant Registry (in the composer JS code, which implements business logic)?
Are these two layers of authentication completely separated? If yes, then how is one supposed to identify in the JS code that a given participant (in composer terminology) is firing the transaction? Thx.
Please refer to the docs here:
https://fabric-composer.github.io/managing/identity-issue.html
The issue identity / revoke identity CLI commands are used to map a Fabric user to a Composer participant.
Related
i have a current channel of hyperledger fabric with chaincode that does CRUD operations my question is that is there any way to make a method in a chaincode that registers the new user when certain condition match.
You can use one of several methods to get the identity of the user:
GetCreator
GetId
GetMSPId
They are part of the Client Identity Chaincode Library, documented here: https://pkg.go.dev/github.com/hyperledger/fabric-chaincode-go/pkg/cid#section-readme
The Hyperledger Fabric docs provide some help for access control also if you're interested in that: https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html?highlight=getmspid#private-data-sharing-patterns
I am playing around with the ERC20 token implemented in fabric-samples. I was wondering if it is possible to not only send tokens between users but have deployed chaincodes receive/hold/send tokens as well. Hence allowing users to send tokens to a specific chaincode and vice versa. This is a very common thing on other blockchains like Ethereum.
To realize this I tried to invoke the erc20 chaincode from my own chaincode via InvokeChaincode and noticed that its documentation states
InvokeChaincode: Locally calls the specified chaincode invoke()
using the same transaction context; that is, chaincode calling
chaincode doesn't create a new transaction message.
which implies to me that chaincode in fabric does not have its own identity but the identity of its callee. Which in turn would make the use case described above impossible...
During researching this problem I stumbled across some old posts briefly mentioning this topic. E.g. here and here. Interestingly SignedProposal seems to contain information regarding the "original" chaincode called by the user. Theoretically, this information could be used in a modified ERC20 contract to identify a specific chaincode but this seems to be a bit hacky to me.
Am I missing something here?
I would appreciate any help. Thanks.
One last thought of mine - but not directly connected to my question: In general just "forwarding" the user's identity to other chaincodes seems to be quite critical from a security point of a view, right?. An adversary could theoretically hide such cross invocations in chaincode and use the callees identity to steal e.g. these ERC20 tokens.
Scenario
Hyperledger Fabric v 2.4
Golang
I am developing a chaincode for Car Registration Record management.
There is a function in my chaincode getCarRegistrationDetails(...) which searches for a car based on input data and returns the result.
Apart from the car registration record, I am also maintaining a credit value for each user (using client identity). When a user request to query registration details of a car, some credit amount is deducted from the user's balance and the car registration record is returned to the user.
Problem
Since I am updating the state in getCarRegistrationDetails(...), it should be invoked. But the problem is that when I call the same function using query it returns the required details but do not deduct from user's balance.
How can I handle this problem in chaincode. More specifically, is there a way to prevent query requests on getCarRegistrationDetails(...) and only allow invoke?
Unfortunately chaincode cannot make that decision. Fundamentally the difference between a client using invoke vs query (in gateway api terms this would be submit vs evaluate) is whether the proposal response (and associated signatures) are then sent to an orderer (invoke) or just the payload is returned to the caller (query), but both an invoke and a query will send the same endorsement request to a peer which is then executed by chaincode.
The way you would handle this is within your client application. Your client application knows which methods should be invoked/submitted and which should be queried/evaluated
I have some questions regarding the deployment of a HLF use case. Suppose we build a platform in which users sell items. The users and their items are stored on the ledger via chaincode. The purpose is to also enforce access control on the items via the chaincode, so that another user for example cannot see a specific item. Then the 2 options regarding the whole identity management are:
The users do not have certificates in Fabric, and all transactions made by the users are forwarded to a single registered Client who interacts with the chaincode. Therefore, the transaction context will always have this client's ID. So from my point of view the username should be always passed to each transaction and implement access control using this username, though a registered Client has full authority over their data.
Every user is registered and enrolled and have their own identity. Every user makes a transaction directly on the blockchain via the chaincode, and access control can be implemented easily by using the stub.ID() and other attributes. That would mean that >100k users would be registered on a CA or multiple CAs.
The questions are:
Is HLF intended and suitable for the 2nd option, or is it made solely for the purpose of interaction between clients of organizations?
Is there a best way to handle this matter?
A ledger stores facts about the history of transactions that led to the current state of an object. The history also stores the users responsible for the current state of the object. If the state of an object is being changed, the admin/authorized user of an organization must be able to see who performed that change.
In the first approach, if you want to see the details of the user doing the "transaction", you'll have to store it somewhere different from the blockchain. While that can be a use-case of your project, it defeats the purpose of storing all facts about the history of a transaction of an object as every time the same user would be doing the transaction.
The second approach fulfills all the motives of incorporating blockchain in a project. Sure, you'll have to register and enroll every user who's creating/modifying an asset but then Access Control Management can be done in a better way. Please read about ACL to know about the granular access you can achieve in Hyperledger Fabric.
Also, you can also encode some information about a user in its x509 certificate with ASN.1
Second option is more preferred and Hyperledger Fabric ca could handled number of user registrations. There is Attribute access control also available which you can use at chaincode level to control use access.
https://www.youtube.com/watch?v=CAXRMJ-quhg
I am new to composer, and now practicing some of the tutorials and examples. But while doing this I can not understand some of the features, so here are the questions which I do not clearly understand:
Are queries restricted by .acl file (when, for example, we use them in rest server)?
Do the rules written in the .acl restrict some of the transactions which are allowed for certain participant to submit? (For example, for participantA it is not allowed to CREATE new participants, but what happens if participantA submits the transaction(which is allowed for him to submit)which creates another participant, will this transaction fail?
Could cards be created by rest api server?(I know that participants could be created using JS api, but is it possible to create and issue the identity for those participants through RestServerApi?)
What happens when PeerAdmin upgrade certain node to a new version? How do other nodes act in this case? Do they upgrade themself automaticly?(Also found that upgrade takes a lot of time(2-4 minutes) when deployed locally, whereas in browser for local connection it takes 3-4 seconds)
Does Hyperledger fabric allow some of the ledger data be stored in one private network, whereas other network connected to the private one would not store this part of ledger( or the data will be simply crypted)? The same question regarding the transactions: will the be executed on outer networks?
Yes Composer Queries (and therein, results) are subject to ACL restrictions or filters.
It will still fail due to ACL rule restriction. Once denied to create, always denied as that is the final operation (in this scenario). The actual transaction would fail.
Yes of course use POST /system/identities/issue REST endpoint (eg http://localhost:3001/api/system/identities/issue) - see an example here -> https://medium.com/#CazChurchUk/developing-multi-user-application-using-the-hyperledger-composer-rest-server-b3b88e857ccc
An administrator with PeerAdmin capability has responsibility to install new version on his peers (in his Org). The other Org peer Admins are responsible for theirs, that's how a blockchain consortium with different Orgs will work. They will agree the 'what' and when but will need to install the new version on own Org's peers, so the new version can be started on the same channel. Of course, there will be a difference between a Fabric infrastructure response time, and that of a web connection using local storage.
Channels in Fabric implement privacy. You can have one or more business networks on that channel (ledger), therefore transactions in that business network are private to that ledger. It is the client's responsibility to encrypt data or not. Hyperledger Composer can allow call one business network from another, on the same channel, or if permitted to do so, on different channels too - see https://hyperledger.github.io/composer/latest/tutorials/invoke-composer-network