I'd like to know how I could do to restrict the access to a chaincode function for a particular client, is it possible to do it through the ACLs or maybe I should do it through the chaincode?
Thanks & regards!
You can try out ABAC (Attribute Based Access Control) of Hyperledger Fabric.
https://jira.hyperledger.org/browse/FABC-539
You can add extra fields/attributes to the x509 certificate of the user while registering/enrolling the user with the CA. Later while invoking, you can check for the attributes in the chaincode.
If the access needs to be restricted based on whether the requester is member of a certain organization, then ABAC is not the right tool for that since anyone can put whatever attributes they want in their certificate. Not only that, it is possible to fake Organization too in the Subject header of X509 cert. In general, do not use metadata in the X509 certificate to determine whether requestor is part of an organization (e.g., there might be a chaincode method that should be restricted to users of your company). To test membership in an org, use the mspID returned by the ClientIdentity [1]. That cannot be faked. If someone tries to fake it, there will be an error on the peers:
2019-05-16 16:12:49.132 UTC [protoutils] ValidateProposalMessage -> WARN c98 channel [mychannel]: MSP error: the supplied identity is not valid: x509: certificate signed by unknown authority
ABAC can be used to restrict further access, but remember ABAC is not the right tool for restricting access based on membership in an org.
What is happening under the covers? When a chaincode is invoked e.g., using the peer chaincode invoke CLI, one of the environment variables that needs to be set is the CORE_PEER_LOCALMSPID (if it is not set, fabric will use the value in the core.yaml file). By setting this variable, the person invoking the chaincode is asserting that they are a member of the org in CORE_PEER_LOCALMSPID. Then when request reaches the peer, the X509 cert provided by the person making the call is validated against the CA of the org they specified in the CORE_PEER_LOCALMSPID variable. This validation is same as if one had run openssl verify -CAfile ca.cert user.pem. Now if the user tries to pretend to be a member of an org that they are not, the validation will fail with above message. Details on how a certificate is verified can be found here. If the chaincode is being invoked using the node sdk, then the msp id is set in network-config.yaml under organizations -> org1 -> mspid. Bottomline, if someone tries to fake it, it will result in error.
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.
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.
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.
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.
I read the docs on Hyperledger Fabric Membership Service Providers (MSPs) and not everything was really clear to me.
The link to the part of the docs on MSPs is this:
https://hyperledger-fabric.readthedocs.io/en/release-1.2/membership/membership.html
Quote from the docs:
This is where a Membership Service Provider (MSP) comes into play —
it identifies which Root CAs and Intermediate CAs are trusted to
define the members of a trust domain, e.g., an organization, either by
listing the identities of their members, or by identifying which CAs
are authorized to issue valid identities for their members, or — as
will usually be the case — through a combination of both.
My understanding of this paragraph is this: An MSP of OrgX either has a list of OrgX's members (so a participant on the network can simply be checked against the list) or, alternatively, the MSP defines which Certificate Authority is allowed to issue identities for members of OrgX.
Is this understanding correct?
If an MSP of OrgX defines the Certificate Authority that is allowed to issue identities to members of OrgX, then how does this protect the network from unwanted participants entering? Let's say that the MSP of OrgX uses "Symantec" as its CA. So everybody with a certificate from Symantec is regarded as member of OrgX and can participate in the network. But what if I (who is not a member of OrgX) get myself a certificate from "Symantec"? Am I now automatically considered a ember of OrgX and can join the network?
There are channel MSPs and local MSPs. According to the docs, both the channel MSP and the local MSP define which identities belong to a certain organisation (for example, OrgX). But what's the point of instantiating the channel MSP to nodes, if the channel MSP contains the same information as the local MSP (namely basically a list of identities)?
My understanding of this paragraph is this: An MSP of OrgX either has
a list of OrgX's members (so a participant on the network can simply
be checked against the list) or, alternatively, the MSP defines which
Certificate Authority is allowed to issue identities for members of
OrgX. Is this understanding correct?
Correct. But... in practice, the only certificates that are explicitly configured in the MSP, are administrator certificates. The rest are not configured, and are verified by standard x509 PKI validation (finding a validation path to some intermediate or root CA), while the admin certificates are identified by a byte-by-byte comparison.
If an MSP of OrgX defines the Certificate Authority that is allowed to
issue identities to members of OrgX, then how does this protect the
network from unwanted participants entering?
Unwanted participants are not expected to have a private key that has a corresponding certificate that is ussed by OrgX.
Let's say that the MSP of OrgX uses "Symantec" as its CA. So everybody
with a certificate from Symantec is regarded as member of OrgX and can
participate in the network. But what if I (who is not a member of
OrgX) get myself a certificate from "Symantec"? Am I now automatically
considered a ember of OrgX and can join the network?
If you get a private key corresponding to the public key of a certificate that is issued by Symantec's CA, and the CA has a certificate that is configured as a root CA or intermediate CA in the fabric channel config, then - you can authenticate as a member of OrgX.
There are channel MSPs and local MSPs. According to the docs, both the
channel MSP and the local MSP define which identities belong to a
certain organisation (for example, OrgX). But what's the point of
instantiating the channel to nodes, if the channel MSP contains the
same information as the local MSP (namely basically a list of
identities)?
the channel MSP doesn't contain the same information as the local MSP.
The local MSP, contains only information regarding the organization that the local MSP's node (peer, orderer) belongs to.
However - a channel MSP, can contain information about any organization that is a member of the channel.
Actually, a channel has several MSPs - 1 for each organization!
Consider an example - you have orgs A, B C in channel Foo.
So, the channel configuration would have 3 MSPs - each used to verify an identity belonging to the corresponding organization.