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.
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 know that each entity in the hyperledger network does need an Identity. This identity is given by an certificate authority. The local and channel MSP maps this identity with an organization and gives the identity a role.
A couple of questions:
What are the roles I can choose from? I know for example there is a role 'Admin', but what else?
Does each role have a specific access, or do I need to specify this somewhere?
Is this a possible scenario: A user with the role 'Reader' and a
peer with the role 'reader'? Or does identities other than users
have total different roles?
Does each node have all the channel MSP's?
Let's say I have a peer with the role 'Admin' and a user with the
role 'Admin'. What is the difference?
Q1: Different roles in the fabric
Admin
Writer
Reader
Q2: Yes, each role has specific access. While creating a channel we need to define all roles. Admin can do configuration block changes as per policies defined.
There are two types of policies
Signature Policy
ImpliciteMeta Policy
The reader can only read transactions, where the Writer can invoke a transaction. We define all policies in channel configuration block.
Q3: Only Organization(Orderer Organization, Peer Organization) has user, not for peer, so user can be one of (Admin, Reader, Writer)
Q4: There are two types of MSP
Channel MSP
Local MSP
channel configuration (channel MSPs), and locally on an actor’s premise (local MSP). Local MSPs are defined for clients (users) and for nodes (peers and orderers). Node local MSPs define the permissions for that node (who the peer admins are, for example). The local MSPs of the users allow the user side to authenticate itself in its transactions as a member of a channel (e.g. in chaincode transactions), or as the owner of a specific role into the system (an org admin, for example, in configuration transactions).
Q5: Only user of Organization have the role of Admin, I don't think peer have admin role, where as peer comes under some organization who will have some users(Admin user would be one of them)
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.
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