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
Related
Considering MQTT's pub/sub behavior, topic namespace is not isolated and any user can access every other user's data on a topic.
I've seen services like flespi which claim they provide isolated name spaces but some of them use containers to isolate users...
Is it possible to modify an MQTT broker, e.g. Mosquitto, for that purpose? Or is there such open source broker?
Mosquitto can set access control to topics based on authentication username. This allows the administrator to restrict access to topics and restrict which clients can subscribe, publish or receive messages on particular topics. This is documented in Mosquitto’s documentation.
For greater flexibility you can also use the dynamic security plugin, or the mosquitto-go-auth plugin which allows you to use a variety of different data sources for authorization and ACL configuration.
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
I'm trying to query the Global Address List using Microsoft Graph. I've worked with and adapted the sample code from https://github.com/microsoftgraph/console-csharp-snippets-sample.git -- however, I'm still having trouble. I've seen this article -- Global Address List Graph API -- which indicates I need to use the "/contacts" endpoint. However, I don't see how this helps me when I'm using the Microsoft.Graph library. Is there some method or collection within the Microsoft.Graph library that will allow me to read the GAL?
"GAL" is a MAPI concept that doesn't really apply to Graph. With Graph, you just read the users or contacts in your company's Active Directory. By combining both lists, you come close to what you'd see in the GAL in a MAPI client.
To do that, you would list users as doc'ed here: https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/user_list
Using the library, I believe this will get you started:
client.Users.Request().GetAsync();
For contacts, it's a lot trickier with the Graph library. Organizational contacts are only supported in the beta version of Microsoft Graph, which the client library doesn't support unfortunately. (See this issue for info). Michael Mainer did a write up of how you can generate your own beta version of the library if you're interested.
The info on querying organizational contacts is found here: https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/resources/orgcontact.
As of late 2021, doesn't appear to be an easy "Export Global Address List" API from Microsoft. There appear to be manual methods (e.g. using the Exchange Admin interface) but nothing programmatic.
Below is broad strokes exercise for creating an approximation (that may be sufficient for your needs). A more accurate exercise may be to export the GAL from a official client (e.g. Outlook/Outlook Web/Exchange Admin interface). Its possible that in some cases the GAL is user specific which may make GAL export concept significantly more involved.
GAL export exercise:
APIs:
MS Graph API (available via HTTP, e.g. GET/POST)
Users
Groups
Some of the above only allowed certain properties accessible by individual record query - I needed to get the whole list then iterate through each record one by one to get all needed properties.
Exchange Powershell (available via Powershell)
Get Mailbox (for flags not exposed by Graph/Users)
Get-DistributionGroup (for flags not exposed by Graph/Groups)
Azure Functions can be used to run these queries serverless/"API-ified". Azure App Registration can be used as OAuth app that can be granted the permissions to access the above. Microsoft Graph Explorer is handy for testing Graph requests.
Put it together:
Smash the datasets together and then filter out on fields. Some flags are:
hideFromAddressLists
hideFromOutlookClients
HiddenFromAddressListsEnabled
showInAddressList,
some conditions you have to manually check for, e.g.
if no provisioned plans (i.e. unlicensed)
if no email address
etc.
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.
Service or daemon authentication to the Microsoft Graph grants access to a limited number of functions.
For example, to be able to work with Planner and tasks, you have to be logged in as a user. In other case, we can't access most of user details, we can't access user's files and so on.
Why service or daemon must have more permissions then now? In our case, service should automatically create Planner tasks and Calendar events for specific users or groups according to automatically registered events. Sometimes it should also create or add or read files in OneDrive of this user. Also automatically, of course. Due to Microsoft Graph restrictions, it is easier to use additional 3rd-party service to track tasks, or even write our own. The same situation with files.
Microsoft Graph looks like a powerful API, but due to its access restrictions it becames unusable when you need to made something automatically, without any user actions.
What is the reason for most of these restrictions?
Is there any walkarounds?
Office 365 works perfect with deamon applications but not in your usecase. It works great for modifying a user' calendar for instance. See here https://learn.microsoft.com/en-us/graph/api/user-post-events?view=graph-rest-1.0&tabs=cs
Apart from that, if you want to have something changed in the graph api. The best way to let Microsoft know is to create an item on UserVoice. This is to let users influence what features they need, maybe you can express your wishes there. https://microsoftgraph.uservoice.com/forums/920506-microsoft-graph-feature-requests