search

provenance-io / provenance

A distributed, proof of stake blockchain designed for the financial services industry.
https://provenance.io
Apache License 2.0
87 stars 37 forks source link

Enhance authz with URL targets and create new metadata authorization #1439

Open SpicyLemon opened 1 year ago

SpicyLemon commented 1 year ago

Summary

  1. Create a new metadata-specific authorization to allow a granter to restrict the authorization to a specific scope, session, or record and only for certain roles.
  2. Enhance x/authz in our fork to allow MsgTypeURLs to have targets (i.e. <msg type url>#<target>).

Problem Definition

Currently, authorizations are too broad. They allow a granter to sign for the grantee for any update (of a message type), even if that grantee shouldn't be involved in the thing they're updating. They also allow the grantee to sign as any role that the granter fulfills.

We need a way to allow a granter to limit an authorization to a specific entity. Furthermore, we need a way to limit the authorization to specific roles.

It want to be able to say something like this, “I grant permission to sign for me as a on the session with id ”

Proposal

There are three parts to this:

  1. A new authorizaiton
  2. An update to the x/authz module in our SDK fork
  3. An update to the metadata module's authz checking to identify and apply these restrictions.

New authorization

Create a new authorization that has a metadata address, list of roles, and optional number of uses.

An empty roles list is the same as having all roles in the list.

The MsgTypeURL() function on this authorization will return a value based on its metadata address. E.g., if it’s a record address, /provenance.metadata.v1.MsgWriteRecordRequest#<record address> would be returned.

The Accept function will only check the number of uses and decrement it if applicable. It doesn’t have enough info to do anything with the roles. And since it can’t be called via Exec, there isn’t any msg validation that can be done that isn’t already being done in the metadata module.

x/authz update

In the x/authz module, when using the MsgTypeURL for routing purposes, strip off any # and everything after it.

Authorizations are unique for a granter + grantee + MsgTypeURL. That MsgTypeURL must also be routable.

Effectively, this would allow authorizations to be granted differently for different specific scopes, sessions, etc.

Authorizations with a fragment would not be usable through the Exec endpoint though, since it wouldn’t know how to add the the fragment. However, due to the 1 signer and 1 grantee restriction of Exec, it’s already effectively unusable for the metadata module.

Updated metadata authz handling

Update our GetMessageTypeURLs function to take in a metadata address and also return values containing that address as a fragment. It doesn't need to be added to all existing return values, only on the ones that might be generated by a new authorization's MsgTypeURL().

For example, if the url /provenance.metadata.v1.MsgWriteRecordRequest is provided to the function, the following should be returned:

Basically, any Write... urls it's returning, should also have the same entry with the fragment, regardless of the reason it's in the list.

When looking for authorizations to fill signatures, if an authorization is found that passes Accept:

For Admin Use

piercetrey-figure commented 1 year ago

SpicyLemon commented 1 year ago

Instead of this authorization have a count field, #1483 should be done so that this new authorization can be placed in one of those if a count is desired.

On second thought, that might cause problems with the MsgTypeURL stuff, so it might not work. But it's something to think about and look into.