Awarded: ICDevs.org Bounty #62 - Role-Based Authentication Class - Motoko $8,000

Developers Bounties
1

ICDevs.org Role-Based Authentication Class - Motoko - #62

Current Status: Discussion

  • Discussion (03/24/2023)
  • Ratification: (TBD)
  • Open for application: (TBD)
  • Assigned (TBD)
  • In Review
  • Closed

Official Link

Bounty Details

  • Bounty Amount: $8,000 USD of ICP at award date.
  • ICDevs.org Bounty Acceleration: For each 1 ICP sent to cec84b9b919384a3ba0fcad11b25411a86b1e67e61f4bbdcfd0a52e25fb7e1c1, ICDevs.org will add .25 ICP to this issue and .75 ICP to fund other ICDevs.org initiatives.
  • Project Type: Individual
  • Opened: TBD
  • Time Commitment: Months
  • Project Type: Role-Based Authentication Class
  • Experience Type: Intermediate/Expert - Motoko and Access Control

Description

The proposed project aims to create a drop-in class for role-based authentication in Motoko. This class will enable developers to easily configure role-based access control and provide role-based checks in their applications.

Role-based authentication is a critical component of many applications, enabling developers to control access to resources and ensure that users have appropriate levels of access based on their role. By creating a drop-in class for role-based authentication, developers will be able to quickly and easily implement this functionality in their applications.

The new drop-in class will be designed to be customizable and flexible, with support for a wide range of role-based access control scenarios. It will also include features for role-based checks, making it easy for developers to enforce access control policies in their applications.

To create the new drop-in class, the project will require an experienced developer who is proficient in Motoko and has a strong understanding of access control. The developer will work closely with the Motoko community to ensure that the new class meets the needs of developers working on the Internet Computer.

The new drop-in class will also include a well-designed and supported, single page HTML file that can be hosted from an access canister and used to update and modify permissions.

Several open-source libraries can be used as a starting point for the role-based authentication class, such as the Node.js library connect-roles, which provides a simple way to manage roles and permissions in a Node.js application.

Role-based access on the IC includes the complications of asynchronous programming and subnets. Role checks on the same subnet may work fine to query endpoints, but cross subnets checks may expose dapps to reentrance risk. Your class should consider these carefully and explain he limitations of the library. A cross subnet solution would be welcome as well.

You may consider drafting a potential ICRC Specification to standardize role based checks across the IC as part of this bounty if you determine that that would be a good idea. Future iterations of the replica may support capability based roles so we do not expect you to solve those problems at this time, but considering and understanding the concepts and explaining the differences and advantages they would provide should be expected in the readme.md file.

Overall, the new drop-in class for role-based authentication will provide a valuable resource for developers working on the Internet Computer, enabling them to easily configure role-based access control and provide role-based checks in their applications, enhancing the security and control of their applications.

This bounty gives the opportunity to

  • learn about Motoko
  • learn about Cross canister and cross subnet state and async calls

To apply for this bounty you should:

  • Include links to previous work building web applications and any other open-source contributions (i.e., your Github).
  • Provide a brief overview of how you will complete the task. This can include things like which dependencies you will use, how you will make it self-contained, the sacrifices you would have to make to achieve that, or how you will make it simple. Anything that can convince us you are taking a thoughtful and expert approach to this design.
  • Give an estimated timeline on completing the task.
  • Post your application text to the Bounty Thread

Selection Process

The ICDevs.org developer’s advisors will propose a vote to award the bounty and the Developer Advisors will vote.

Bounty Completion

Please keep your ongoing code in a public repository(fork or branch is ok). Please provide regular (at least weekly) updates. Code commits count as updates if you link to your branch/fork from the bounty thread. We just need to be able to see that you are making progress.

The balance of the bounty will be paid out at completion.

Once you have finished, please alert the dev forum thread that you have completed work and where we can find that work. We will review and award the bounty reward if the terms have been met. If there is any coordination work(like a pull request) or additional documentation needed we will inform you of what is needed before we can award the reward.

Bounty Abandonment and Re-awarding

If you cease work on the bounty for a prolonged(at the Developer Advisory Board’s discretion) or if the quality of work degrades to the point that we think someone else should be working on the bounty we may re-award it. We will be transparent about this and try to work with you to push through and complete the project, but sometimes, it may be necessary to move on or to augment your contribution with another resource which would result in a split bounty.

Funding

The bounty was generously funded by the DFINITY Foundation. If you would like to turbocharge this bounty you can seed additional donations of ICP to cec84b9b919384a3ba0fcad11b25411a86b1e67e61f4bbdcfd0a52e25fb7e1c1. ICDevs will add .25 for every 1 token donated to the bounty. All donations will be tax deductible for US Citizens and Corporations. If you send a donation and need a donation receipt, please email the hash of your donation transaction, physical address, and name to donations@icdevs.org. More information about how you can contribute can be found at our donations page.

FYI: General Bounty Process

Discussion

The draft bounty is posted to the DFINITY developer’s forum for discussion

Ratification: (01/09/2023)

The developer advisor’s board will propose a bounty be ratified and a vote will take place to ratify the bounty. Until a bounty is ratified by the Dev it hasn’t been officially adopted. Please take this into consideration if you are considering starting early.

Open for application

Developers can submit applications to the Dev Forum post. The council will consider these as they come in and propose a vote to award the bounty to one of the applicants. If you would like to apply anonymously you can send an email to austin at icdevs dot org or sending a PM on the dev forum.

Assigned

A developer is currently working on this bounty, you are free to contribute, but any splitting of the award will need to be discussed with the currently assigned developer.

In Review

The Dev Council is reviewing the submission

Awarded

The award has been given and the bounty is closed.

Other ICDevs.org Bounties

3 Likes
2

Hey , not asking officially yet , but can i still work on it to see if i can make a suitable solution ?

3

Hello everyone. Skilesare let me participate in this task.

I have a few questions:

1)Will we need a Bella-Lapadula model or only a role-playing one?
That is, the role model assumes one administrator without delegation of authority.

2)Which services will be used for authentication?
Let’s say Plug; Stoic; II; there are different APIs. Which one should I take as a basis?

I am also willing to share (or take) some of the work with interested developers.

I’ll write a plan of action a little later.

4

I’ve submitted you…coordinate with agentDPS if you want some help.

You’re asking great questions. Can you lay out the implications of making different decisions based on 1?

As far as 2, I think we’d want to look at supporting as many as possible. Maybe use connect2Ic?

1 Like
5

Hi lets collaborate on this , if you are willing to do so

6

Hi! I already have a minimally working option. I’ve done both backend and frontend. It needs to be finished there, but they are workers.
As a result, I have a ready-made RBAC, but I don’t want to show it now. Firstly, it is minimal, secondly, refactoring is needed, there are a few more issues that need to be addressed.

7

Hi

The first working option.

Source code link (github): GitHub - fury02/rbac-motoko

Frontend (web canister): https://gyuwx-hqaaa-aaaan-qdw2a-cai.icp0.io/

Frontend is built on Vite - React

Rbac canister (backend): DFINITY Canister Candid UI

The main idea:

In this version, it is based on authorized calls to the Rbac canister.

The Rbac canister accepts these calls. Authenticates the user using the built-in Internet Computer (shared ({caller })).

As an example:

public shared ({caller }) func whoami_caller() : async () {
assert (controller(caller))
// Get roles
// Next logic
};

Next, a check is performed (depending on the function of the call) for:

-is the caller an administrator (controller canister)

-is the caller an Rbac user

In case of problems, an exception is thrown. If the verification is successful, the user gets their roles (permissions). Further, in accordance with the logic of the application, we can restrict access or allow certain actions. The Web application has a demo version in the “Check” tab

Schematically:

sheme
sheme966Ă—736 33.8 KB

There are a few of my comments:

  1. There was no refactoring of the backend code

  2. A different elliptic curve is used (Ed25519) and for which it is necessary to add another Identity as the administrator of the canister controllers

  3. Attack vectors (overcoming protection) in the Web application are not sufficiently studied

  • it is worth noting that reading (changing) resources such as arrays; collections guarantees 100% protection when properly encoded and using the Rbac class.

Example: backend/rbac/impl; src/components/checking_access

skilesare what are your comments and suggestions?

I would like to clarify more about the use of Stoic.
Within the framework of this task:
We cannot use Connect2Ic since we only get Identity in it, it does not allow signing messages. Internet Identity has limitations of working with Linux.
I have not fully tested the capabilities of the Plug wallet, it will be possible to integrate this wallet (Plug + Stoic)

8

Is there any way that this pattern can be rewritten without requiring an inter-canister (update) call?

Maybe look into either encrypting roles and passing those around like an RBAC token to call other canister services with (i.e. JWT), or using the new composite queries feature when it comes out feat: composite queries by crusso · Pull Request #4003 · dfinity/motoko · GitHub

I’m just not sure that 4+ seconds to verify a role will be quick enough for most developers and applications.

9

I didn’t understand the question.
If we are talking about stable structures, then yes. Any update of the canister does not overwrite roles, permissions, issued permissions, etc. Everything is saved. GitHub - fury02/stable-hash-map: Stable hash maps for Motoko; GitHub - ZhenyaUsenko/motoko-hash-map: Stable hash maps for Motoko

This requires my consideration.

I’m currently busy working on Plug wallet connectivity options. To create an identification agent inside the request. Since Stoic is currently only supported. Next, I will return to your questions.

Yes, it’s a long time. But it works and I hope it’s completely safe;) I think this option is also viable, provided that there will eventually be solutions based on authentication tokens.

Thanks for the suggestions!

Update 1
About security (concealment of information). No one can read what roles and permissions are present in the system except for the canister controllers. I haven’t removed the extra features yet, but eventually it will be like this.

10

General

scheme (simple)

1)Begin:
Identification
Canister; User
a)The WEB user is identified on the site using the providers Intenet Identity; Stoic; Plug(with the fetchRootKey error Plug), receives Identity and KeyPair
b)The canister is by definition self-identified inside the IC

2)A canister with the RBAC class accepts the request. It can be another canister or a WEB user. Identifies the caller shared({caller}). It is understood that we trust {caller} by default.

3)RBAC finds the {caller} and gets the roles (permissions) assigned by the administrator.

4)The simplest option: (in fact, it has already been presented)
The RBAC class is built into the actor where there are resources. Access to resources is carried out by permissions. Each new resource request requires a new call.(maybe not)
End.

scheme (with tokens)

1)Begin:
Identification
Canister; User
a)The WEB user is identified on the site using the providers Intenet Identity; Stoic; Plug(with the fetchRootKey error Plug), receives Identity and KeyPair
b)The canister is by definition self-identified inside the IC

Next step:
2)A canister with the RBAC class accepts the request. It can be another canister or a WEB user. Identifies the caller shared({caller}). It is understood that we trust {caller} by default
Next step:
3) RBAC finds the {caller} and gets the roles (permissions) assigned by the administrator.

Next step:
4) Option with tokens:
4.1)The RBAC class generates an access token. Roughly following the JWT standard (JSON Web Tokens ; https://jwt.io /)
4.2)Encrypts: token; roles; permissions;
4.3) The RBAC class sets the lifetime of the token, and keeps it. RBAC deletes the token after the token lifetime expires.

Next step:
5)The RBAC class sends the data structure {token; role; permissions} to the consumer.
Next, the consumer(Canister; WEB User)

Periodically polls RBAC for the validity of the token.
Variants:
-The token is relevant: we are not doing anything.
-Token deleted (time expired):
canister - return to step 1
web user - return to step 1
End.

What does the use of the token give:

  • Restrictions on the number. You can restrict the receipt of tokens on Identity
  • Data on roles and permissions are relatively up-to-date. See point 4.3
  • Avoiding the problem of inter-network collisions?

@skilesare There are ways to improve. Let’s make it better.

11

Hi!
There are results:
https://gyuwx-hqaaa-aaaan-qdw2a-cai.icp0.io
I made the Web interface work very responsive.
The work has not been completed yet there is something that needs to be investigated
Now:
Access tokens are used ( standart https://jwt.io)
You can write your IDs so that I can add them and test them yourself. I can make skilesare an administrator.
@skilesare, @icme can you comment.
I will also add a scheme of work…

1 Like
12

Hi!
This is the first version where the identified shortcomings have been fixed.
And some improvements have been introduced.
I will consider it the final version
Links:
Rbac it self is distributed via MOPS
https://mops.one/rbac-motoko

WEB Administrator source:

WEB:
https://gyuwx-hqaaa-aaaan-qdw2a-cai.icp0.io/

13

I’m sorry it has taken so long for me to get to this. I’m taking a look now.

Once I’m logged in with my II I see the following…maybe that is my principal? Do you need to add me as an admin?

Execute commands before starting using:

1) Run command dfx
dfx canister --network=ic update-settings rbac --add-controller se3xx-ziaaa-aaaan-qdsta-cai
2) Run command dfx
dfx canister --network=ic call rbac add_admin “(principal "4po65-fesy7-xuaep-wjzez-c7gfr-xa6r6-bupho-lqduy-jvkuu-xvuvl-fqe")”
3) Run commands dfx:
dfx canister --network=ic call rbac init
14

Ok
I added as an administrator 4po65-fesy7-xuaep-wjzez-c7gfr-xa6r6-bupho-lqduy-jvkuu-xvuvl-fqe
Only he’s also a canister controller now. That’s it should be.

You can associate the role and your Principal in the Roles tab with the array_read role. And check in the Check tab for read access to the array.

  • The first time it will read only the first two arrays.
  • You will need to log in again. Then three lists of arrays will appear.

One more thing:
If you try to build the project locally and run a local replica, it may not work. It is better to immediately load into your cans directly into the IC.

15

If someone wants to test in the presented canisters (WEB and RBAC) I can add you as a user and give you some roles (permissions). I can temporarily make the members of the Dfinity team administrators(users). You can also start your service if there are free canisters :upside_down_face:

16

I’d love any help from the community that I can get in vetting the code and application…If your dapp may need role-based security, please check this library out and test out the dapp!

1 Like
17

lib: link
dapp: link
I will add: the web application is an RBAC control canister. You can build any other application (including the RBAC administrator) based on this library. The security of your application will depend on you.

18

I have updated the documentation. A little information about the RBAC integration architecture and about the token itself.

A little bit about security issues:
This web application (at the links above) is presented solely for demonstration purposes. To use RBAC in your projects, you need to deploy your WEB-Admin and RBAC instances in your canisters, with your keys, under your control.

19

Please check your DMs.