amavic / bmerode-generator Goto Github PK

Add a transaction that allows to retrieve the history of a given business object based on its ID

Handling authorization check for collaboration setup

When generating the code for the Participant Business Object Types, a public key attribute must be added (in attributes, constructors, etc.)

When executing an ending method that is triggered because of an ending method in a dependent object,
the top method rejects the event execution because of existing "living dependents" (that will, actually be removed in the end)

The code generator does not generate the CollaborationSetup lastIds structure for all business object types.

In the XSD File (1.6): an element of type MetaMPCKind is expected but not added in the generated XSD Files.
As a temporary fix: put minOccurs = "0" in the XSD for that element

To be implemented

When users try to perform operations that are not allowed, the operation is well denied.
However, the reason why is not clearly displayed (mess with Exceptions).

Compared to the proposition in the original paper, instance access rules can be simplified.
We only consider instance access rules for event execution: conditions specifying whether a particular instance of a participant is allowed to execute a given business event.

For instance:

• EPT: EV_end_IdentityRequest allowed only for Citizen (participant type)
• IAR: identityRequest.citizenId = sender (Citizen).id

To do for implementation:

• For Each Business Event, foresee IARs in the XSD (see issue)
• Parse IARs (transformation engine)
• Generate IARs checks in the smart contracts (check positioning + add to other events than create)

• Multiple Propagation Constraints
• Aliases
• Inheritance
• Various (OCL) constraints
• Input Validation Checks

• Formalize CREATE flow and verify in current implementation
  • Create full BOT JSON from input JSON (requires #7)
  • If masters
    • Check if masters exist and are not in final state (note: check for final state is handled by the master's current state)
    • For ED with cardinality 1: Check if there is already a living dependent of the same time for the chosen master
    • If either condition is not met, send erro
  • Save the newly created BO (will be rolled back if needed)
  • Trigger event handling in masters
• Formalize MODIFY flow and verify in current implementation
• Formalize END flow and verify in current implementation

Implement a JSON Validator allowing to make sure any JSON Strings provided as parameters are valid for a given call

To be implemented

The version of the org.hyperledger.fabric-chaincode-java:fabric-chaincode-shim library is not fixed in build.gradle, which causes issues with the generated chaincode.

Fix: org.hyperledger.fabric-chaincode-java:fabric-chaincode-shim:2.5.0

The gradlew shell script is not copied from the base chaincode structure into the generated chaincode directory.

Manual Testing of the Key Components to prepare for Case Studies: All Successfull (after a couple of committed adjustments)

• Model Files used as Input: BMerode-Solution-Testing-Models.zip

• Testing Scenarios and Results: BMerode-Solution-Testing-Scenarios.txt

The different participants are handled in the scope of the collaboration being supported, distinctively from HLF's identity system. Indeed, access control lists and policies that can be defined on HLF are independent from the chaincode. It does support the assignation of attributes to different identities, which can be used to encode permissions. The chosen solution makes it easier to handle participants as regular business object types and allow organizations to use B-Merode without needing to affect user identities on their blockchain networks.

In this context, each participant BOT has a public key (which can be retrieved when it submits a transaction).
When users send transaction proposals to the network peers, these proposals must be cryptographically signed, and HLF verifies the correctness and validity of the signature. Therefore, having a mapping (public key --> role --> permissions) is sufficient to verify, at chaincode level, whether a given user has the right to perform a given transaction.

While the Event-Participant Table defines which participant (type) is allowed to fire business events, and thereby, among others create, modify or end participants, we still need a way to handle this when the collaboration is not running yet. Indeed, if participants of a given type are allowed to create other participants, the former must well be added by someone.

Thereby, we introduce two elements:

• A special user which is always created: The ParticipantsHandler. It has all the permissions to create, modify or end participants as long as the collaboration is not marked as "ready"
• A state for the collaboration (setup/ready). Once it's in "ready" state, the ParticipantsHandler is no longer available, and regular permissions apply

This is consistent with the general idea that even if organizations collaborate in a trustless and decentralized manner, one needs to make the initial setup (c.f. HLF docs).

This has a number of implications:

• When executing a transaction (or firing a business event), we first check whether the collaboration is ready:
  • If the collaboration is not ready, only C/M/E of participants is allowed, only for the ParticipantsHandler
  • if the collaboration is ready, regular permissions apply, and the ParticipantsHandler is disabled

Current solution does generate all required files, but does not include in the package the files that do not depend upon the model and need to be added to the solution "as-is"

• BOT name
• BO state
• BO id

Develop JSON Converter:

• From input JSON to workable (backend) JSON
• From backend JSON to front-end JSON

Event-Participant Table

Defines which Business Event can be fired by which Business Object (Participant) Type.
Default: not allowed.

Transactions Handling

markCollaborationAsReady

Once the setup of the collaboration is ready (required participants (BO) have been added), the ParticipantsHandler can specify it using this transaction.

handleEvent

Upon reception of a request to handle a Business Event, the following checks must be performed:

• Check if the collaboration is marked as ready
  • if the collaboration is not ready
    • check if the sender is the ParticipantsHandler and reject the request if that's not the case
    • if the sender is the ParticipantsHandler, then check if the Business Event is about CRU of a Participant Business Object
      • if this is the case, then the event is accepted
      • if not, the event is rejected
  • if the collaboration is ready
    • fetch the business object that is linked to the sender's public key
    • check in the Event-Participant Table whether the fired event is allowed for that type of participant
    • warning: Instance Access Rules are not implemented at this stage

Implications for implementation

• The Event-Participant Table must be stored in the .mxp file (see issue)
• The Event-Participant Table must be generated as part of the smart contract (for now) (see issue)
• For each Participant Business Object, a public key attribute must be stored (see issue)

To be Implemented

Potentially same issue as getBO / getBOHistory (that are fixed)