I have recently started to learn the Hyperledger Besu, and what I am trying to do is actually compare Besu with Fabric and see if it is compatible with my already finished Fabric project.
I know from Fabric that using the CA from an organization we can create new users that are under that org. Also, there is the option to name this user with a username and add some custom attributes that can be used in the chaincode like attribute role for example.
Now, in Besu I have only discovered so far that only with some third party tools like MetaMask and the js library web3j we can create accounts. Although, those accounts are in the form of Public Key/Address & Private Key.
Is there something that I have missed out?
Is it possible to have somehow similar user accounts in Besu like Fabric?
Thank you
After my own research I have concluded that these are the only ways to create accounts for Hyperledger Besu:
MetaMask Wallet
web3 js library through javascript
In order to have more specific accounts that may be connected with some user information or roles that could determine various things in the application, the most suitable option is the following:
Use a centralized database to store the user information and associate it with the users address. This database could be used from a client application where the user can login with his/her credentials or using a third-party wallet like MetaMask.
Also, to distinguish the users inside the smart contracts the best option so far seems to be the library of OpenZeppelin Ownable
Related
whenever I look for a new blockchain project it is asked to make an admin first before adding any other members. And also whenever I instantiate a new build I have to create an admin. Why is it required? Why can't I directly create members and start my nodes?
HF is an permissioned network, the only Admin has permission to install query and upgrade the chain code ,similarly every member have to register himself with admin as know user inside fabric before doing any transaction. it is predefined in architecture.
I have a running website, where users already have accounts. And I am trying to create a Google Assistant agent, accessible on Android, to help users access their information.
My issue is that I can't detect returning users on Android Smartphones, each time they have to sign in.
I tried Anonymous User Identity, but it is soon to be deprecated.
Is there an other way to keep track of users?Using some kind of userId that I can store, so I can make "my own Acount Linking" linking the person/Smartphone with already existing user accounts.
There are a few angles to your question.
Is there any way to keep track of users?
Yes... but...
You can store a userId that you generate in the user storage area. You do need to treat this like you would a cookie, so some jurisdictions might impose restrictions on this, but this is one approach to moving from the anonymous ID that is being turned off soon.
But...
How do I let them log into my service through the Action?
That is the problem. The General Policies states the following limitation for collecting user data:
Authentication Data
(including passwords, PINs, and answers to security questions)
Don't collect authentication data via the conversational interface (text or speech).
After a user's account has been linked, PINs or passwords may be used as part of a second verification process.
So you need to use Account Linking to connect to the existing account on your service.
How can I do Account Linking if I don't require Google Sign-In?
You can still use Google Sign-In for Assistant if it will (or may) provide the information as part of the profile that match what you have. So it doesn't need to use the same account - just have the same email (for example).
But that still may not be enough.
For other cases, you can look into setting things up to work with an OAuth server that you control.
So why use Google Sign-In if I setup an OAuth server that uses Google Sign-In?
Google Sign-In is good for a more streamlined flow, if you can use it. It can be done completely with voice, such as with a smart speaker, instead of requiring the user to go to a phone to complete the login. So if you have the user's email address in your account system, and you also get this from Google Sign In, then you can connect the two accounts.
In some cases, such as if the user is expected to have logged into the account on your website first, they won't even need to do that. If both the voice client and web client use the same Google project, then authentication will take place automatically.
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 am working on a project where I need the functionality of user registration and user login. I need some suggestion. What would be the better way of achieving this task?
A.) Old school email & password OR B.) By using public & private keys?
What I understand from option B is that we need to enroll a user from CA from Fabric-SDK. Once enrolment of user is done, we can generate a unique password-phrase like the same is happening in Meta-Mask. We can store that user info along with its username (the default username in fabric is user1, user2) with password-phrase.During user login, it will ask for user's private key or the unique password-phrase generated for its account. The certificates will be stored in hfc-keystore (the default dir used in Hyperledger fabric). Whenever a transaction is executed by that user say user akshay.sood, we will set the context of that user to fabric-client (Please correct if I am wrong in this case).
Here, My questions/queries are:
1.) What do you prefer (email/password or private/public keys and why?).
2.) If you prefer 2nd mechanism then how will you protect user keys and certificates stored in hfc-keystore dir. I mean it can be hacked or data can be stolen by hacker.
3.) How to recover user private/public key and certificate if it is deleted mistakenly from hfc-dir.
4.) Would you prefer using password-phrase? if no, what do you prefer?
Edits are welcome.
Please let me know if you have any suggestion/improvements
Your question is a choice of your preference, convenience & business needs. You can use either or both approaches in combination. Asking the user to keep or manage his private keys calls for a managed wallet. However, IMHO, if you are concerned about leakage or loss of private keys then you would need a Hardware Security Module that is specifically designed for this purpose.
P.S. Fabric & its examples store the keys in hfc folder for simplicity, although not recommended in real cases.
In our application, we can have a lot of users. (10000 ++)
We would like to give our users the opportunity to sign their transactions, list their assets, in a private environment.
They have their own end users and assets, and will be able to manage them through the network.
At first, our users would use our network, and then we hope to be able to offer them a higher level of privacy by allowing them to interact with their own network. (via the ledger)
We have built a system using composer where our end users (our customers) have their own identities. But we need to be sure we will not have any limitations. Knowing that with this scheme, the number of participants can become huge and the management of identities could become a nightmare
We searched, but we did not find information related to the limitations of such a system built with hyperledger composer.
We understand that a business network is private, but in the case of a SAAS application what would be your recommendations?
So it sounds like you want to give organisations access to a SaaS application and (ultimately) maintain separation (privacy) of the ledger - for an individual organisation (and its users).
You can deploy the SAME business network (smart contract and deployed business model) on separate channels (as in Fabric channels) so then each organisation will have its own ledger. Furthermore, you as the SaaS provider can either issue identities from a central CA registrar in the SaaS network - or - more likely - each has access to their own CA to issue identities (ie certificates) - however that's configured - so that their users can sign transactions (eg from the application).
Those users would connect to their business network (and access that ledger) via business network cards - the 'card' contains the identity information and connection metadata to connect to the deployed business network (from the application in question, eg via the APIs). After an end-user signs in, a check can be made to see if they have a busness network card, to be able to interact with the ledger.
Its likely that the SaaS provider or individual organisations would (through some UI or management capability) issue the cards and have them persisted/stored centrally/securely - ie so the SaaS application running in the end-user's browser(say) can access the user's wallet in that org, which contains the business network card and identity info - just one possible implementation example).
The building of / issuing of cards can be automated (as can the creation of a participant in Composer - which maps to an identity). A CA server will issue a certificate for each identity registered, and each unique identity would therefore have a unique business card (miniscule footprint ie < 1k). Does that help ? So I don't see a major 'limitation', nor a major overhead in what you propose.