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
Related
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/
some questions about service accounts and best practises on GCP.
1) I'm able to create a "brand new" service account. How can I ensure that this new service account doesn't have any kind of privileges bound to it? I'm asking this because for a project I need to create multiple service accounts with only one permission: write access to a single Google Storage bucket. Nothing more. How can I ensure that this is the only granted permission and nothing else ?
2) Should I create a new Google Cloud Project for every customer I have, in example, one project for each website that I'll host to GCP or a single company project (in this case, my company) would be enough to hold all Compute Instances, Storage buckets and so on, needed by my customers ?
Managing hundreds of project would be overkill, if possible, i prefere to avoid this, without impacting secutiry.
Thank you.
You can only constrain service account permissions to enabled services that implement IAM (the Google Cloud Platform services including Cloud Storage). For services that don't implement IAM, the only way to limit a service account's auth is through OAuth scopes.
Projects appear provide a more robust security perimeter for you to separate your tenant customers. Additionally, you get enforced separation of billing, logging, auditing etc. It's debatable whether managing per customer projects (each owning a bucket and related service accounts) has different security than a multi-customer project (with many buckets and service accounts) since service accounts may be easily extended across projects. I recommend whichever path you choose, you ensure control is effected programmatically to minimize human error of granting one customer's account(s) to another customer's bucket(s).
HTH!
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.
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
I have a Rails app acting as an OAuth 2.0 provider (using the oauth2-provider gem). It stores all the information related to users (accounts, personal information, and roles). There are 2 client apps that both authenticate through this app. The client apps can use the client_credentials grant type to find users by email and do other things that don't require an authorization code. Users can also log in to the client apps using the password grant type.
Now the issue we're facing is that the users' roles are defined globally on the resource host. So if a user is given an admin role on the resource host, that user is admin on both clients. My question is: what should we do to have more fine-grained access control? I.e. a user can be an editor for app1 but not for app2.
I guess the easy way to do this would be to change the role names like so: app1-admin, app2-admin, app1-editor, app2-editor, etc. The bigger question is: are we implementing this whole system correctly; that is, should we be storing so much info on the resource host, or should we denormalize the data onto the client apps?
A denormalized architecture would look like this: all user data on the resource host, localized user data on each client host. So user#example.com would have his personal info on the resource host and have his editor role stored on client app1. If he never uses it, app2 could be completely oblivious of his existence.
The drawback to the denormalized model is that there would be a lot of duplication of data (account ids, roles) and code (User and Role models on each client, separate management interfaces, etc.).
Are there any drawbacks to keeping the data separate? The client apps are both highly trusted--we made them both--but we are likely to add additional client apps, which are not under our control, in the future.
The most proper way to use oAuth and other similar external Authorization methods as I see it, is for strictly Authentication purposes. All the business/authorization logic should be handled on your server part at all times, and you should always keep a central record of the user, linking to the external info per external type of auth service.
Having a multilevel/multipart set of access, is also a must, if you want your setup to be scalable and future-proof. This is a standard design that is separate from any authorization logic and always in direct relation to business rules.
Stackoverflow does something like this, asking you to create an actual account on the site after you login using an external method.
Update: If the sites are really similar you can subset this design to an object per application that keeps the application specific access rules. This object has to also inherit from a global object that has global rules (thus you can for example impose a ban application-wide or enterprise-wide).
I would go for objects that contain acess settings, and roles that can be related to instances of both application level settings and global settings only for automating/compacting the assignment of access.
Actually you can use this design even if they are not too similar. This will help you avoid redundant settings and meaningless (business-wise) roles. You can identify a role purely by the job title/purpose, and then impose your restrictions by linking to an appropriate acess settings setup.