In the Fabric-ca-server-config.yaml, i see following comment in registry section
2) once authenticated, **retrieves the identity's attribute names and
# values which the fabric-ca-server optionally puts into TCerts
# which it issues for transacting on the Hyperledger Fabric blockchain**.
# These attributes are useful for making access control decisions in
# chaincode.
My question is how to make it compulsory for ca sever to add these attribute to Tcerts?
For the default setting roles and attributes are not included in the generated certificates
Although the fabric-ca-server supports putting attributes in tcerts (transaction certificates), the clients including SDKs do not yet support using tcerts. They currently always use ecerts (enrollment certificates). There is a jira item which would allow putting attributes into ecerts also. See https://jira.hyperledger.org/browse/FAB-3752. You can track the progress and make any additional requests via jira.
Related
I was trying to enroll a user with the Fabric Go Client.
I have recently changed my Go lang version to 1.17 and after that I am receiving this error: X09: certificate relies on legacy Common Name field, use SANs instead
Although I have passed the extra hosts using custom CSR (which will result in setting up the SANS in the CSR request) while enrolling the user.
If there is anything extra which needs to be done let me know.
As per the docs, I have to pass the CSR hosts which I am passing already.
Thanks,
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.
I need to know about Hyperledger fabric and fabric CA
1. How to create the orderer and peer certificate and key pair using fabric-ca
2. How to query the affiliation and CA name using fabric, do we need to write chain code and query them, or can I query them without using chain code through fabric node js.
3. I see Domain in crypto-config file. Do I need run any domain service or need to buy some domain name. If I am using fabric ca is there anything equivalent to a cryoto-config domain?
4. Is it possible to update the member details once it's created? If it's possible, if I change the password of the member or affiliation of the member does the certificate will get reflect to?
By registering entities, enrolling both MSP and TLS profiles, and copying missing stuff between folders. Make your own scripts if you wish. https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/users-guide.html#fabric-ca-client https://hyperledger-fabric-ca.readthedocs.io/en/latest/clientcli.html
https://fabric-sdk-node.github.io/release-1.4/FabricCAServices.html https://godoc.org/github.com/hyperledger/fabric-sdk-go/pkg/client/msp
That domain in crypto-config is used to compound peer and orderer domain/names, as you should have observed. As always, you can buy a domain, use docker internal name services or work directly with IP addresses if you wish. Everything works if you configure it correctly. Be careful that TLS certificates include the domain name or IP used in CN or SAN fields (--csr.hosts parameter in fabric-ca-client).
You can edit an identity, enroll the new certificates that reflect those changes and update your nodes with them whenever you want. Be careful that certificates inside admin folder define which certificates are recognised as admin (the admin role is per certificate, not per identity), so re-enrolling an admin certificate can be tiresome.
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
Background
I am studying the hyperledger fabic tutorial: Building Your First Network (BYFN), and studying the details of the scripts. The source codes can be found here.
Question
The commandbyfn.sh generate runs cryptogen generate ./config=./crypto-config.yaml and then generates certificates. A directory crypto-config/ is produced with sub-directories ordererOrganization/ and peerOrganizations/.
In the path crypto-config/peerOrganizations/org1.example.com/. It consists of
ca/
msp/
peers
tlsca/
users/
I have difficulties in understanding the structures in this directory.
Q1: There are certs and private keys in ca/, msp/ and tlsa/. But what are they representing? and why do we need them? It confuses me because inside directory of peer/, there are also msp/ and tls/.
Q2: What is the purpose of users/ directory? (I only know the network has peers and orderers). Are user and admin representing the end-users for this organization? and what is the difference between user and admin? Take this network picture for example, where are user and admin?
Many Thanks
So, public channel configuration is loaded only with what is found under msp/.
This is used to verify certificates of clients, and network nodes (peers, orderers).
The ca/ folder just represents what a CA would have had it exited.
The tlsca/ folder is basically used to define the same thing the ca/ folder, only for TLS certificates. In fabric, there is a different certificate chain for TLS and for enrollment certificates.
Now, the peers, orderers , users contain the material for the local MSP of the node, as well as its signing identity (certificate, and private key).
The user is basically anyone that can authenticate to fabric as a client, and an admin is a special type of users who is authorized to sign transactions that have administrative changes on the organization it belongs to, like - adding anchor peers when sending a configuration transaction to the orderer, or - instantiating chaincode.