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.
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.
In Hyperledger, does the decentralization ends at the organization level?
or can it be also extended after the organization level i.e in the peers and client level?
According to what I understand -> if he/she wants then the Admin of an organization is able to control everything and take control of any Peer/ Client/ Member and can access their rights and do transactions by their name.
can we say that the Admin completely owns the organization?
Not sure you can say that an Admin completely owns the organization. What an admin or non-admin user can do is determined by access control lists. These determine who can do what. When combined with endorsement policies, one can ensure that changes require decentralized agreement.
I am setting up a solution to transfer data securely and in a permissioned manner between users of two different organisations (Data resides within organisation database system and not on Blockchain). From Blockchain controls like abac (attribute based access control), I can make the user get relevant details needed to access data. Now, I am writing a middleware for the user in the second organisation to call and get the data. In this context, is it possible for the middleware to check the user from second organisation is actually who he claims to be by checking with the CA of the second organization ?
As long as you are admin of both organizations you can check any user.
fabric-ca-client identity list --id user1
You can use NodeJS API for the same operation
Check this
https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/users-guide.html#attribute-based-access-control
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.
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.