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.
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.
As far as I understand the hf.Registrar.Roles attribute defines the roles that the identity I'm creating can register when this identity in-turn registers new identities. What does the hf.Registrar.DelegateRoles attribute define? Any research online leads me to believe it performs the same fucntion as what the hf.Registrar.Roles attribute does. If someone can point out the difference between the two and explicate how they both make a difference in a practical scenario, it would be of great help. Thanks.
hf.Registrar.Roles - these are the roles which the registrar is allowed to assign to users it registers
hf.Registrar.DelegateRoles - these are the roles which the registrar is allowed to assign to the hf.Registrar.Roles attribute of users it registers
For example, the "super" admin may want to register a user which is also allowed to register users but may want to restrict that user from creating additional registrars or may want to limit the roles it can create registrars for.
So let's say hf.Registrar.Roles="client,user,peer" but hf.Registrar.DelegateRoles="client". This means the registrar can register users with roles client,user or peer but can only create additional registrars with the attribute hf.Registrar.Roles="client".
My question is on access control in hyperledger fabric composer.
Assume you have a business network, in which you have the following participants:
Sellers
(Potential) Buyers
A seller is an employee of a company that sells products to a buying company. A buyer is an employee of a buying company.
Example:
The buying company is Daimler. Three employees of Daimler are registered as Buyers in the network.
The selling company is General Electric. Two employees of General Electric are registered as Sellers in the network.
With hyperledger composer's Access Control Language, one can restrict the access rights of buyers and sellers at will.
But how is the situation regarding Access Control at the Node level?
There are not only buyers and sellers but also two system administrators: one system administrator responsible for the Daimler peer and one system administrator responsible for the General Electric peer.
By default, the system administrators have access to all data. That is, the Daimler system administrator has access to all data of the registered General Electric employees. Vice versa, the General Electric system administrator has access to all data of the registered Daimler employees.
Is it possible to restrict the access of the system administrators to a handful of rights, such as:
right to install and start the business network
right to control changes to the system made by the other system administrator (e.g. if the Daimler system administrator changes the code of the application, then the General Electric administrator must approve those changes before they can become effective)
Read Access to employees of one's own company
Access to a hyperledger fabric (for anything including interacting with a business network) is managed by hyperledger fabric MSPs.
Hyperledger fabric, as part of the setting up of the hyperledger fabric network and channels, define which identities (created via the MSPs) have the authority to install chaincode onto peers and which identities have channel authority, to be able to instantiate or upgrade chaincode.
It is possible to restrict Peer Install and Channel instantiate/upgrade to specific identities.
Information about Hyperledger fabric MSPs for example can be found at this link https://hyperledger-fabric.readthedocs.io/en/release-1.2/msp.html but you will probably want to be familar with the complete operations section this section is part of.
Access control in Composer is done via participants and the business network ACL file. You control which participants can perform various actions on resources controlled by the Composer runtime.
You need an identity (generated by your MSP) in order to be able to interact on a channel/chaincode (as required by hyperledger fabric) this identity has to be previously mapped to a specific participant in order to the interact on the business network. When a request is sent to a business network, composer will look up that specific participant based on the identity that made the request and use that participant and it's type to determine, through the information in the business network ACL file, what it is allowed to do.
Note that things like Peer install, channel instantiate/upgrade of chaincode is a fabric level capability, not a composer capability so you do not control these types of activity through composer ACL definitions
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.