Macaret
Macaret

Reputation: 797

Hyperledger Composer - ACL issue

I need some help to understand how exactly the Access Control Login works in Composer. I've studied all the available demo's I could find only but I still need some guidance.

I have the following participant:

abstract participant Business identified by email {
  o String email
  o String name
  o String legalEntity
}

participant Insurer extends Business {
}

and the following asset:

asset Policy identified by policyId {
  o String policyId
  o PolicyStatus status
  o DateTime signDate

  --> Insurer insurer
}

and the following transaction:

transaction SwitchPolicyInsurer {
  --> Policy policy
  --> Insurer insurer
}

async function switchPolicyInsurer(tx) {

  var NS = 'org.example.mynetwork';
  let policy = tx.policy;
  let newInsurer = tx.insurer;

  // Save the old Insurer
  let oldInsurer = tx.policy.insurer;

  // Update the policy with new owner
  var factory = getFactory();
  policy.insurer = factory.newRelationship(NS, 'Insurer', newInsurer.getIdentifier());

  //Update the asset registry
  let policyRegistry = await getAssetRegistry(NS + '.Policy');
  await policyRegistry.update(policy);
}

I have created a Policy with relationship to Insurer_1. What I need is when I switch to Insurer_2 identity, and try to use the SwitchPolicyInsurer transaction to receive an access error. Basically, only the Insurer from the Policy should be able to switch the relationship to another Insurer.

I've tried the following in ACL:

rule SwitchPolicyInsurer {
  description: "Can switch"
  participant(m): "org.example.mynetwork.Insurer"
  operation: READ, UPDATE
  resource(v): "org.example.mynetwork.Policy"
  condition: (v.insurer.getIdentifier() == m.getIdentifier())
  action: ALLOW
}

It doesn't work, any Insurer Identity can use the transaction. Another odd thing is that I can set any string as the insurer and the relationship is saved.

I'm using the Browser as a testing ground.

Upvotes: 0

Views: 99

Answers (1)

Paul O'Mahony
Paul O'Mahony

Reputation: 6740

I see Policy asset now has the field 'insurer' and the model for Insurer participant has been added.

UPDATE: your problem is: you've got other rules defined, and the precedence / order of those is affecting what you want to restrict etc. I suggest to try these rules (only) below, along with the normal system / network ACLs (so normal operations can function) that you probably already have at the bottom - in general, ACLs are like a pyramid - the more fine-grained rules (affecting 'less' target resources) go nearer the top - the more 'coarse' rules (because of their very nature, tend to go to the bottom of the ruleset, affecting a broader set of target resources).

rule txn_rule {
  description: "Access the txn resource itself"
  participant: "org.example.mynetwork.Insurer"
  operation: ALL
  resource: "org.example.mynetwork.SwitchPolicyInsurer"
  action: ALLOW
}

rule marshal_rule_via_txn_only {
  description: "Marshal updates such that transacting insurer participant matches the linked/related policy"
  participant(m): "org.mynetwork.trading.Insurer"
  operation: READ, UPDATE
  resource(v): "org.example.mynetwork.Policy"
  transaction(tx): "org.example.mynetwork.SwitchPolicyInsurer"
  condition: (v.insurer.getIdentifier() == m.getIdentifier() )
  action: ALLOW
}


rule policyresource_rule_outside_txn {
  description: "Need base access to my (insurer) policy resource outside of the transaction itself - used ALL, but could equally have READ"
  participant(m): "org.example.mynetwork.Insurer"
  operation: ALL
  resource(v): "org.example.mynetwork.Policy"
  condition: (v.insurer.getIdentifier() == m.getIdentifier())
  action: ALLOW
}

rule playground_rule_so_I_can_see_identities_to_switch_and_test {   // can be removed when done with testing FYI
  description: "self-explanatory"
  participant: "ANY"
  operation: ALL
  resource: "org.example.mynetwork.Insurer"
  action: ALLOW
}

Upvotes: 1

Related Questions