In hyperledger composer network permissions, we always come across these terminologies
Composer Network and Composer Identity.
Network access and Business access.
Registries and Networks.
What is the difference between them, how far I know registries are for participants and assets, you can access participants and assets using registries and define permissions?
For permissions, you can read about the ACLs here -> https://hyperledger.github.io/composer/reference/acl_language.html
'Composer Network' represents the business network entity. 'Composer Identity' refers to a specific blockchain identity that is mapped to a single Participant - defined in a Participant Registry that is contained within the business network in question.
Registries maintain a particular type of view of an Asset, Participant . Registries are also maintained by Composer for Identity or Historical transactions. It allows someone in that business network (given the right authority) to see the current status and history of the ledger, and Registries classify that much like a database table might do - ie depends on the level of details required (eg. Backroom Traders (Participant), Front Office Traders (Participant), Metal Commodities (Assets), Agricultural Commodities (Asset) etc etc) - or could just be rolled up as 'Traders'(Participant) and 'Commodities' (Asset) types if less detail is required. The salient point is you store Participant - or Asset Instances - in their respective type registries.
See the tutorials for examples of Assets and Participants in action:
https://hyperledger.github.io/composer/tutorials/queries.html
https://hyperledger.github.io/composer/tutorials/developer-guide.html
Related
I was reading this documentation https://github.com/digital-asset/daml-on-fabric but I am confused. I am trying to understand the workflow and the architecture for the daml on fabric network. The network has 2 orgs and each org has 1 peer.On step 4 are allocating 5 daml parties. Quickstart example has 3 signatories(issuer,owner,buyer). To sum up, what is the match between daml parties and fabric orgs? I think that could be allocated even more daml parties without to change fabric network. They interact from one node? What is the purpose to add other nodes on step 11?
Parties don't have a cryptographic identity in DAML Ledgers, only nodes do. As part of the shared ledger state, every DAML-enabled infrastructure maintains a mapping from Party to Node. This relationship is usually described as a Node "hosting" a Party. The Node hosting a Party is able to submit transactions using that Party's authority and is guaranteed to receive any transactions visible to that Party.
In the tutorial you are referring to, all parties are allocated on a single Node, which then hosts them. This does indeed not make that much sense in practice. It would be more sensible to set up a network with three orgs and allocate the three parties on the peer nodes in the three orgs, respectively. Given the way the example is set up, that should be straightforward.
I am currently automating the creation of an hypeledger fabric network. The fabric-ca-server has no affiliation when i start and then I add them one by one.
Can the orderer get the organizations somewhere else than the configtx.yaml (e.g. querying the affiliations in the fabric-ca-server) ?
No, you have to define your organizations in the configtx.yaml file only, as it uses that file to generate the genesis blocks for your system and application channel. So whichever organizations you are using in your network that must be the part of the orderer genesis block which is generated only through configtx.yaml file.
I am looking for DA’s recommendation/best practices regarding writing and deploying DAML code and object (.daml and .dar) in production grade solutions.
Let us take a scenario - Central Authority (CA) operating node may issue a new role under a contract to Participant 1 (P1) by writing a simple DAML code, below are few questions related to the DAML deployment –
a. Assuming DAML code will be written by CA, can we say that only CA needs to have this code and its build on its node and CA will simply execute the contract workflow allowing Party on P1 Node to simply accept/reject the role without having to know the content of the DAML code (business logic and other contract templates) written by CA ?
b. Will the DAML code file (.daml) written by CA Node needs to be transmitted to Participant 1 (P1) node so that P1 can verify and agree with the DAML file code (contract templates, parties and choices) and put the code and its build (.dar) into its node as well?
c. If the answer to above question is yes, how will the integrity of the DAML code be maintained e.g. what if DAML code is changed by P1 or CA at the time of deployment, which may cause conflict later?
The contract model, in the form of a dar file has to be supplied to all nodes that participate in the workflows modeled in that dar file.
A dar file can contain multiple DAML "packages" and each package is identified by its name and a hash.
On ledger, contract types (called template) are fully qualified, including package hash. If you change your templates, the package hash changes and thus the new templates are seen as completely different from the old ones by the ledger.
To change an existing contract model, you have to upgrade existing contracts using a DAML workflow. Of course, all signatories of the existing contracts need to agree to the upgrade workflow. You can only unilaterally upgrade data that you are in full control of. In the crypto currency world, you can consider all miners as signatories. Either they all agree on an upgrade or they hard fork, leading to two slightly different models of the same currency.
This sort of model upgrade process in DAML is described in detail here: https://github.com/digital-asset/ex-upgrade
Given an application that shows objects (e.g. films) according to certain user permissions.
The general permission to show or create objects is implemented as RBAC with roles and permissions.
The specific permission to access an object with certain attributes (e.g. a film with the attribute “drama”) should be implemented with memberships. That means the object doesn’t have the property “drama”, it is a member of the group “drama”. If the user and the object are members in the same group, the user has the specific permission to access this object. There can be different groups for showing, creating or deleting an object, like a simple viewer group or some kind of editor group. Furthermore there is a table that specifies which group types are relevant for certain actions on certain objects. For example relevant groups for the action “show” on the object "film" could be “genre” and “age” (film's suitability for certain audiences).
The reason to implement it in the described way is to have great flexibility without touching the code. Changes to groups can be processed in the database.
General database design:
Example: The film "The Revenant" is a member of the groups "genre:drama" and "age:18". The user can access it, if he is a member of these groups too.
Does this sound like a good approach? Are there any existing solutions that are similar to this approach? Does it have major drawbacks (e.g. too many database queries - there may be several hundred users every day)?
Please share your thoughts on this issue with me - the choice of "drama" as category for the example is not a coincidence ;) I just dont know if this is a dead end or if I am heading to the right direction. I stuck at this point for quite a while.
At least you have a good sense of humor :-)
Your approach sounds fine. So long as you keep the number of parameters low, then you can get away with role-based access control (RBAC) and a few additional parameters e.g. group membership.
But in the long run, if you want to implement business-driven authorization (access control), you need a way to do this independently of your code: you do not want to rewrite your app code every time there is a requirements change.
To do so, there is an access control model called Attribute-Based Access Control (ABAC) that will let you define your authorization policies independently of your code.
In ABAC, you have the following concepts:
an architecture which defines a policy enforcement point (PEP) and a policy decision point (PDP). The PEP sits in front of (or within) your app. It intercepts the business requests (e.g. a request to view a film) and sends an authorization request to the PDP. The PDP is configured with policies. Based on the request the PDP will reach a decision: either yes, Permit or no, Deny.
a policy language: the policy language is attribute-based (hence the name ABAC). This means that you can use any number of attributes (e.g. user role, user id, user group memberships, but also user age, user location, user subscription as well as resource attributes such as movie rating, movie category, movie price...)
a request / response scheme: this is how you ask for authorization. It is essentially a yes/no flow. "Can a user do X?", "Yes they can."
There are several implementations of ABAC out there - some of which are framework-specific e.g. CanCanCan. XACML and ALFA are two approaches that are not tied to any particular framework. You can choose from open-source and commercial implementations of either language e.g.:
Open Source: SunXACML, ATT XACML
Commercial: Axiomatics Policy Server
I'm trying to understand if a DHT can be used to solve a problem I'm working on:
I have a trading environment where professional option traders can get an increase in their risk limit by requesting that fellow traders lend them some of their risk limit. The lending trader can either search for traders with certain risk parameters which are part of every trader's profile, i.e. Greeks, or the lending trader can subscribe to requests from certain traders who are looking for risk.
I want this environment to be scalable and decentralized, but I don't know how traders can search for specific profile parameters when the data is contained in a DHT. Could anybody explain how this can be done?
Update:
An example that might make it easier to understand might be SO, but instead of running as a web application, the Risk Exchange runs as a desktop application on each trader's workstation. The request for risk are like questions (which may be tagged by contract, exchange, etc) and each user has a profile which shows their history of requests, their return on borrowed risk, etc.
Obviously the "exchange" can be run on a server, but I was hoping to decentralize it and make it scalable so that the system may support an arbitrary number of traders. How can I search for keywords, tags, and other data pertaining to a trader's profile if this information is stored in a distributed hash table?
Your question holds a contradiction in my ears. DHT is a great way of distributing data in a decentralized manner, but cannot provide the nodes with an information overview. This means that any overview action, such as questioning the network for certain data, will have to be done at a centralized collection point. Solutions to this contradiction has been created, but their fault tolerance does not match a critical system such as financial trading.
So my answer would be to use a centralized server to hold an overview cache of the DHT network.