I do want to implement my own identity version of MSP. I mean instead of default PKI based Identity validation, signature verification, I would like to do that using token based identity validation and signature verification.
Please let me know if it is possible to override the default certificate based authentication/validation with custom authentication and validation in MSP.
Regards,
vdr
Yes, it is possible to support multiple types of MSPs. The design is to support multiple types of identities (i.e. MSP types) concurrently, not just one at a time. This means that one organization may use the default X509-based type of identities, another organization may use the idemix (short for "Identity Mixer") type of identities, and another organization may use yet another type. These three organizations can transact on a single channel.
An idemix MSP type is currently being implemented which supports advanced crypto based on zero-knowledge proof. You can look at fabric/msp/idemixmsp.go in the master branch to get a feel for how to implement your own MSP type. But before starting, I would encourage you to see if idemix will meet your needs. You could also ask more specific questions on the #fabric-crypto rocket chat channel if you want to learn more about idemix.
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.
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.
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 new to hyper ledger and was going through the documentation to get some insight of hyperledger especially in Channel Configuration (configtx) section.
There they defined that
Channel configuration has the following important properties:
Versioned: All elements of the configuration have an associated version which is advanced with every modification. Further, every
committed configuration receives a sequence number.
Permissioned: Each element of the configuration has an associated policy which governs whether or not modification to that element is
permitted. Anyone with a copy of the previous configtx (and no
additional info) may verify the validity of a new config based on
these policies.
Hierarchical: A root configuration group contains sub-groups, and each group of the hierarchy has associated values and policies. These
policies can take advantage of the hierarchy to derive policies at one
level from policies of lower levels.
Can somebody explain me the third point with some example?
Here is the link for above paragraph http://hyperledger-fabric.readthedocs.io/en/release-1.0/configtx.html
The most important way that the channel configuration is hierarchical has to do with policy evaluation. There is a policy type called an "implicit meta policy". This policy type's evaluation depends on the evaluation of policies deeper in the tree.
Take for example the /Channel/Admins policy. The default value for this policy is an implicit meta policy with a rule of MAJORITY Admins. This rule implies that a majority of the sub-groups must have a policy named Admins, which evaluates to true for the /Channel/Admins policy to evaluate to true. In standard application channel, there are two sub-groups: Application and Orderer. Each of these have an Admins policy which is, by default, also MAJORITY Admins. The /Channel/Application/Admins policy will require that the Admins policy of each of the sub-groups evaluates to true. These sub-groups are application organizations, each of which has a default Admins policy which may be satisfied by a signature from one of their admin certs.
So, the end result of this hierarchy is that to satisfy the /Channel/Application/Admins policy, it requires that a majority of the application organizations admins agree. To satisfy the /Channel/Orderer/Admins policy, it requires a majority of the orderer organizations to agree. And finally to satisfy the /Channel/Admins policy requires that both a majority of the orderer organizations and a majority of the application organizations agree.
Finally, with these policy behaviors in mind, hopefully the natural organization of the configuration as 'hierarchical' makes sense. Configuration elements near the root of the configuration generally require agreement from the entire network to modify. As elements get further from the root and closer to the leaves, the number of stakeholders diminishes, and modifications can be made with less agreement. For instance, an organization may modify its own CRL or CAs without requiring agreement from any other organizations in the network.
ELI5 please. Why ACL policies in example https://github.com/hyperledger/fabric/blob/release-1.2/sampleconfig/configtx.yaml specified in different places (in "organizations", "orderer", "channel" and "application" sections)? What does mean these levels? What is the difference?
In which cases which one should I use? And why in some blocks only policies defined, but in other policy + ACL ("application" section)?
PS: what the difference between channel and org, orderer policies? For example, what happens when I specify "MAJORITY admins" on channel section, "ANY members" on channel and "ANY admins" on org section? What will change in this case for me as an application developer?
ACL(Access Control List) policies are defined as per different logical structures (namely channels,orderers etc.) so you have more control for each of these logical structures and you can define which identities on your network can do what kind of operations ( for simplicity considering them to be Writing, Reading or Admin Related Operations) for each of these units separately.
So as an application developer too, you need to be specific of the policies you define. The keywords(ImplicitMeta policy definers) ANY, ALL and MAJORITY define how many signatures you need to satisfy the policy. For example, if you want to add an organization to your channel in an already running network, you will be needing a few signatures from Admins (which is defined as admin identities from SampleOrg in your cited link). The number of these few signatures depend on the choice of this keyword at network bootstrap time, if you use ANY , even a single signature would do your job whereas MAJORITY would require signatures from a majority of the specified existing identities and ALL would require signatures from all the desired existing identities. Failing in getting the desired number of signatures would leave the policy unsatisfied and hence this operation/transaction won't be successfull.
As in the above case we were trying to make a change at channel level,we can also make changes at orderer level or so and hence we have separate policies for the Access Control. You might get a clearer view on this via the official docs :Here
the ACL policies are written to refer to the policies in the channel configuration. The channel/application path is is the section of the configuration. The syntax is a bit obscure, but channel/application/readers refers to allowing the readers on the channel to access the resource governed by the policy, while channel/application/writers restricts the resource to writers on the channel.
You can learn more about the ACLs and their syntax here: https://hyperledger-fabric.readthedocs.io/en/latest/access_control.html