Currently in Hyperledger Fabric 1.0 there is a central membership service. I want a way to make it decentralized so that atlas 50% of the members have to agree for a new member to join the network. How can I achieve this?
The idea is basically put the membership logic in chain code and let member service fetch data from chain code at the time of enrollment. But how to enforce this, I mean how do we know that membership service is actually reading from blockchain and not cheating.
This is actually natively support by Hyperledger Fabric, and the behavior you describe is actually the default for channel membership changes.
Each channel begins life with a genesis block. The contents of this genesis block define the channel members, as well as policies for which users from these organizations are authorized to perform different functions on the blockchain. For instance, some users may be allowed to submit transactions, but not read the whole blockchain, while others could do both.
To change the channel membership, you submit a channel reconfiguration transaction. This transaction specifies the new membership, and must include enough signatures to authorize this modification. By default, this is signatures from the admins of a majority of the organizations.
The policy framework is actually quite powerful, and with a little knowledge, you can define even more powerful rules. For instance, you could require that OrgA and 3/10 other organizations sign off to change membership. Or, you could require that all but one Org agree to make any membership change, or an infinite number of other permutations.
Some links you might find helpful:
http://hyperledger-fabric.readthedocs.io/en/latest/configtxgen.html
http://hyperledger-fabric.readthedocs.io/en/latest/policies.html
http://hyperledger-fabric.readthedocs.io/en/latest/configtx.html
The documentation and tools around reconfiguration are a little lacking at the time of this writing. The most useful place you can probably look is:
https://github.com/hyperledger/fabric/tree/release/examples/configtxupdate
There are two protobuf structures you must familiarize yourself with, the common.ConfigUpdate, and the common.Config. Channels are created by submitting a signed config update to the ordering service, which generates a corresponding config embedded in the genesis block.
The policy which governs membership changes for a channel is specified as the mod_policy field of the Application group, which is a subgroup of the Channel group. This field defaults to Admins, which refers to the policy definition Admins within the Application group. By default, this policy is set to MAJORITY of the Admins policies for the organization groups defined under the Application group.
So, to modify this policy before creating your channel, you would decode the configtx to JSON using the configtxlator tool, make your modifications, and then encode it back using the configtxlator tool once again. Submitting this new transaction will create the channel with the policy you specified.
If you wish to modify membership after the fact, the process is similar. Retrieve the current channel configuration, decode and modify it, then use configtxlator to compute a config update structure which represents your change. Gather signatures via peer channel signconfigtx then submit it to modify your channel's configuration.
This process is obviously all a bit manual at the moment, but in the future, common tasks should be automated by the SDKs and the tooling should improve as well.
Note: configtxlator is a REST service so that it can be accessed conveniently from inside your SDK application, independent of language.
As a quick addendum. You asked how you can be sure that no one is 'cheating' and not really getting the required signatures. This is also built into the system. All changes to the channel configuration are validated not only by the ordering network, but by all peers in the system. If a configuration arrives which cannot be validated, then all nodes in the network will notices, and will halt usage of that channel until corrective administrative action is taken.
For decentralised membership, that is not dependent on a centralized CA, take a look at Blockstack.
Related
I have a microservice architecture, where one Single Page Application accesses three different APIs:
I am securing those APIs via the Microsoft Identity Platform and therefore I also need service principals.
My first approach matches with all the examples I found on blogs or in the MS docs.
In this case I have one app registration for the client app and three additional ones for the APIs:
This has the following impact:
Each API has its own audience.
I get four service principals for each application.
I get three different places where I have to administrate the user assignments to roles. (for example: User A can read assets from API A etc...)
This works, but comes also with some problems:
The other admins that are managing which user is allowed to do what are confused about three different places they have to assign roles. It would be nicer to have one central place.
The roles of the users are not placed in the ID tokens, because only roles of the client application would go there... but I do not want to assign permissions in the client app again.
If API A wants to call API B or C, I need two access tokens for other APIs.
This lead me to a second idea:
Here I have one registration for all 3 APIs. This already solves problem 1 and problem 2. But it also gives me a strange feeling, because I never found other people doing so.
Also my ID tokens are not telling me the roles, so to fix this, I could even go another step further to a single app registration for everything:
Now one registration exposes an API and consumes this API also. Something what is possible and seems to solve my problems. I even get all roles for the users in my ID tokens AND in my access tokens now.
However, this is contradictive to all other examples I found.
Which disadvantages does the last solution have?
Which of the three approaches should I chose?
Which disadvantages does the last solution have?
One thing that comes to my mind is that you want API A to be able to edit data in e.g. MS Graph API, so you give it the app permission to Read/Write Directory data.
Now with the shared app registration this permission has also been given to API B and API C.
So the principle of least privilege may be violated in the second and third options.
But it does make it easier to manage those APIs as you noticed.
The third option does open up the door for the user to acquire access tokens to any APIs that you might want to call on behalf of the current user from your APIs.
So if you wanted to API A to edit a user through MS Graph API on behalf of the user, you'd have to require the read/write users delegated permission (scope) for your app.
This would allow the user to acquire this token from your front-end as well, even though that is not intended.
Now they would not be able to do anything they wouldn't otherwise be able to do since the token's permissions are limited based on the user's permissions, so this might not be a significant disadvantage.
Which of the three approaches should I chose?
As with many things, it depends :)
If you want absolute least privilege for your services, option 1.
If you want easier management, I'd go with option 3 instead of 2.
There was that one thing I mentioned above about option 3 but that does not allow privilege escalation.
We're developing an application with microservice-based architecture where users can be members of organizations, and within each organization, they may have resource-based access restrictions. An example can be a recruiter who's a member of several organizations on the platform; in organization A they may see the list of all job postings and interviewers while in organization B they can only see job-posting that they are directly allowed to see.
Structure wise this becomes something like this:
All this seems easy to do with Keycloak, we create confidential clients(one for each microservice) and enable resource management on them. However, there are quite some cases when different microservices (i.e., Keycloak clients) need to validate user's access scopes to the same resource. An example would be a setup where we have 2 microservices one for posting & managing job announcements the other for managing applications and interviews, so job-manager and application-manager. Now, when a new application is submitted, or an interviewer tries to access an application application-manager has to make sure that the user has access to the job posting(resource) configured in the job-manager Keycloak client. Which, I think, is not something Keycloak supports.
Scale wise, we're speaking about X00k users, 4-5 times that organization users connections, and tens of millions of resources. So to minimize the number of objects we're creating in Keycloak, we've decided to make use of attributes on resources in which we store JSON structures.
So, how one microservice, can verify a user's access to a resource manager by another microservice?
Try to enable fine-grained authorization:
https://www.keycloak.org/docs/latest/authorization_services/#_resource_server_enable_authorization
This allows for resource based authorization. The resource does not have to necessarily be each resource you have, but an abstraction like an org_manager etc...
Alternatively you can take the json you already have and ask an OPA agent with a policy you defined.
https://www.openpolicyagent.org/
I am a beginner with hyperledger composer, I am not clear with ACL (access control) in hyperledger composer. Sorry, if my question have problem.
Why we need ACL?
When we use it?
Where we use it?
To control access to resources on the ledger, or the kinds of CRUD operations (can I create an asset, can I update an asset), or kind of transaction types a participant of the business network can perform.
Because you want to apply access control - security 101 !
It is applied usually within the realms of a business network. So if I have a business network called 'Commodity Trading' I may only wish 'Trader 1' (a participant) to see his own historical trades on the business network - and not see others' trades. Yet I may allow him (by access rules) to be able to execute certain trade types, because of his role, in that Trade Brokerage. You get the picture.
ACL stands for Access control language and constitutes an important part of our composer network. Hyperledger as we know is a permissioned blockchain and ACL helps in achieving that. It helps in writing rules which define the different access levels of any participant of the ecosystem. We can define whether a participant can CREATE, READ, UPDATE or DELETE asset. We can restrict their access to the assets as well.We use ACL whenever there is are participant at different levels in our network and we don't need each of them to perform every operation on the assets.
You must go through this link once : https://hyperledger.github.io/composer/v0.16/reference/acl_language
Is there a way to make transactions in SawTooth private?
I know HyperLedger Fabric has "channels" and Quorum has private transactions, so looking for something similar but don't see it:
https://sawtooth.hyperledger.org/docs/core/releases/latest/architecture.html
Of course theoretically one could implement encrypt/decrypt process, but this cumbersome to track (if it is an encrypted or decrypted payload)
Since Sawtooth is permissioned it is possible to set up users that have different roles and access rights. This would allow you to create transactions that are private to specific identities.
You can configure a validator to only accept transactions from identities listed in a local config file. Or, use the identity namespace to set the allowed identities, which will be checked when a transaction is received from a client or when a block is validated.
See the identity transaction family for more details of how Sawtooth manages identities and permissions:
The identity system described here is an extensible role and policy based system for defining permissions in a way which can be utilized by other pieces of the architecture. This includes the existing permissioning components for transactor key and validator key, but in the future may also be used by transaction family implementations.
The identity namespace:
Encompasses ways to identify participants based on public keys
Stores a set of permit and deny rules called “policies”
Stores the roles that those policies apply to
There is an experimental feature called Sawtooth Private Data Objects (PDO). Blockchain objects that are kept private through encryption.
For more information, see https://github.com/hyperledger-labs/private-data-objects/tree/master/sawtooth
For docs, see links in this tweet: https://twitter.com/kellymolson/status/1019299515646406656
Alternatively, you can encrypt your payload so others without a private key cannot see it in the blockchain. Or you can just store a hash/checksum in your payload.
We can use Private Transaction Families provided by the Hyperledger labs.
https://github.com/hyperledger-labs/private-transaction-families
The system is based on a generic distributed ledger infrastructure (Hyperledger Sawtooth) and an Intel® SGX (Software Guard Extensions) 'hardened' Transaction Processor which provides a mechanism to enable Hyperledger Sawtooth to contain private information that is both not publicly available but required to validate transactions.
For more information about how Private Transaction Families work, see the following link
https://github.com/hyperledger-labs/private-transaction-families/blob/master/SPECIFICATION.md
Is it possible to allow for someone in hyperledger rights only to read, and to others read+write?
So, can you specify different roles for users?
I'm going to answer the question based on Hyperledger Fabric v1.0.0.
The short answer is yes.
There are a couple of areas to discuss:
1) Ability to send (broadcast) and receive (deliver) transactions to/from the ordering service.
As you know, in order for transactions to make it to the ledger, they must go through an ordering service. An ordering service can be divided up into channels (in simplest terms think of channels as being unique ledgers). Each channel has policies which define who is able to read and write from/to the channel. The documentation on this topic is being updated, but basically there are channel reader and writer policies. If you cannot "write" to the channel, you cannot submit transactions to the ordering service. Additionally, if you don't have access to write to a channel, you cannot send endorsement proposals to peers for chaincode which is deployed on channel you don't have write permission for.
These policies are all part of channel configuration transactions (for which the documentation is currently being updated / created).
2) Chaincode
Beyond the channel-based policies mentioned above, it is also possible to restrict access to chaincode functions as well. This is actually typically handled from within chaincode itself and it is up to the deployer / developer of the chaincode to handle this (especially in the current 1.0.0-alpha release). There is some additional work underway to add some access control libraries which will make doing this a lot simpler