Page History

...

Background

Iroha Special Instructions and Iroha Queries processing requires to have a permissions based security model.

...

Only grantable permission is given to anaccountdirectlyan account directly. An account that holds grantable permission is allowed to perform some particular action on behalf of another account. For example, if accountaaccount a@domain1gives domain1 gives the accountbaccount b@domain2a domain2 a permission that it can transfer assets — thenbthen b@domain2can domain2 can transfer assets ofaof a@domain1to domain1 to anyone.

As you can see permissions were a first-level entities in Iroha 1 while they can be easily implemented by Iroha Special Instructions + Assets.

Solution

pub mod isi {
	...
	enum Instruction {
		Add(...),
		Register(...),
		...
		Check(permissions::isi::CheckInstruction),
	}
}

pub mod permissions::isi {
	pub struct CheckInstruction<C, O> {
		condition: C,
		object: O,
	}
}

Signature of `Instruction::execute` method provides an ability to return error result which for `Check` variant will prevent execution of Instructions for which account has no permissions. Each OOB Instruction and Query will include `Check` instructions in it:

impl Register {
	fn execute(...) -> Result<...> {
		Check{|account| account.asset("role") == ADMIN }.execute(...)?;
		...
	}
}

In this example you can see that we do not need to add permission related attributes to the `Account` and can use assets instead.

The same can be done with custom permissions, storing them in assets components of the account.

Decisions

Alternatives

Concerns

Permissions can be implemented as Iroha 2 Module and stored as assets under account that "owns" them. Then all out-of-the-box Iroha Special Instructions and Iroha Queries will trigger execution of permission check.

Permission check is an execution of `FindAssetsByAccountIdAndAssetDefinitionId` Iroha Query result and check that set of assets is not empty (containing permission needed).

Additionally to solving the problem it brings interesting advantages:

• we do not need to worry about Genesis Block and Network Setup problems (manual initial state configuration vs disabled state during genesis block commit) - we can place permissions module related entities (domains, asset definitions, triggers) commit after basic entities (root account, etc.) commit
• usage of Iroha Queries as a declarative API gives an ability for performance improvements (caches, batch executions, etc.)
• Iroha modules and users can "deploy" own permissions and checks without a need to compile them or to restart Iroha Peers
• private blockchains that do not need permissions module can remove it from the Genesis Block
  • `+` growth in performance
  • `-` additional client-side security checks needed

Decisions

• Store permissions as Iroha Assets
• Check permissions by Iroha Triggers
• Place initial configuration inside additional Permissions Iroha Module and apply it from the Genesis Block

Alternatives

1. Use Iroha 1 approach with roles and grantable permissions:
   1. `+` Out-of-the-Box permissions grouping by roles
   2.  `-` hardcoded permissions checks and additional low-level logic
2. Use assets, but do hardcoded permissions checks inside instructions
   1. `+` less client-side actions needed
   2. `-` no ability to clean genesis block  processing and configuration

Concerns

Assumptions

• Iroha Triggers support pre-instruction hooks because it will be more effective to check permissions before instructions execution

...

Risks

Additional Information