Managing users and roles on ICP with Internet Identity

internet-identity
1

Hello everyone, I am new to the ICP how best to manage users and assign roles on the ICP blockchain.

First and foremost, I understand that if you are authenticating with the Internet Identity (II), every user gets a unique identity/principal for each front-end canister. If the back-end is capturing the authenticated principal, is it safe to assume that this principal ID will never change as long as the user keeps signing in with II to the front-end dApp?

Imagine a scenario where you are building a dApp say for a doctor’s office. The doctor, along with the front office staff will have to use this application, each with different roles and permissions. How will this all come together from the perspective of the IC? Is every user (the doctor and all the front office staff) expected to create an Internet Identity? This does not seem to be feasible or practical. If the doctor decides to create an Internet Identity (on his device), can he share that with his staff? Even then, how will the staff sign into said dApp given that the dApp authenticates with II and attempting to use the doctor’s II number on another computer (by the front office staff) will not work.

I would appreciate if someone can explain how to create a dApp that allows for the dynamic management of roles and permissions for the dApp’s users. How will the dApp’s users also authenticate, for example in this imaginary case of a doctor’s office dApp where the doctor and dynamically create roles (and users too?) and assign to users. I am not sure it is feasible that each user create an II. Even if this were the case, how do you associate the users to this particular doctor’s office?

Thanks in advance for your feedback.

Cheers

2

Hi @srcChain

Thanks for the questions.

If the back-end is capturing the authenticated principal, is it safe to assume that this principal ID will never change as long as the user keeps signing in with II to the front-end dApp?

Yes, exactly.

Is every user (the doctor and all the front office staff) expected to create an Internet Identity?

Yes, Internet Identity is an identity provider for individuals, hence the binding to personal devices (Passkeys).

This does not seem to be feasible or practical.

Why not? This is usually how identity is handled also in other systems. You create a new identity for every user and the separately permission them according to your requirements (either with specific roles or by mandating attributes, etc.).

If you were to only create one identity and share it with the whole team, you would have no way of distinguishing the individual staff members in the back-end. Most likely the staff members should have different permissions, so that is a non-starter anyway. Also for auditing purposes (i.e. who did what) it is important to separate authentication and authorization, even if everybody has the same access rights.

Even if this were the case, how do you associate the users to this particular doctor’s office?

Well, it is the case. What you are touching upon here are the onboarding flows. There are several ways of doing that, but essentially you’ll have to solve the same issues with every system regardless of whether you use Web3 or Internet Identity at all.
One very straight forward way of associating an Internet Identity with a person, is by giving them an access code over a trusted channel which they then can use later to associate their principal with the doctors office system. In practice, this could mean that when you onboard a new employee you hand them the code on a physical piece of paper together with other things they need (i.e. the door batch and other things).

If you want a fully digital process, you can of course send this access code over any other authenticated channel.

I hope this helps. Feel free to ask additional questions and maybe describe your use-case in more detail so that we can suggest solutions better tailored to your needs.

Regards
Frederik

3

Thanks Frederick, I appreciate your responses.

What I meant by not being feasible / practical was (considering our hypothetical case of a doctor’s office, say with 10 front office users), it doesn’t seem practical to ask all 10 users to create an II first, before being able to use the app. I kind of see your point too since users for all apps typically have to create a username and password to start using the (Web2) app. Maybe it will help if I describe the use case and we can discuss the on-boarding flows.

Say the requirement is building a dApp on the IC to be used by any number of doctor’s offices (could be to schedule patient appointments, prescribe meds, etc). Each doctor;s office can have any number of front office users who will be using the app for that specific doctor’s office. For each doctor’s front office, we need a user with role to read and write patient data, and users who can only read the patient’s data.

From your suggestion of a possible onboarding flow: the doctor creates his/her II and registers his/her doctor’s office in the same step (while logging in with the II). The backend canister returns a code (could be the unique office id created from the registration step above), which he then makes available to the front office users. The front office user creates his II, uses that and the access code to login. Is this a correct assumption? Is there a best / recommended practice vis a vis these kinds of workflows?

I appreciate your feedback.

Thanks

1 Like
4

Hi @srcChain

What I meant by not being feasible / practical was (considering our hypothetical case of a doctor’s office, say with 10 front office users), it doesn’t seem practical to ask all 10 users to create an II first, before being able to use the app. I kind of see your point too since users for all apps typically have to create a username and password to start using the (Web2) app.

Internet Identity (in this scenario) takes the place of a Web2 solution (which also requires every individual user to sign-up). I still don’t quite see, why creating an II for every user would be a problem. And I’d be curious to hear what you think should happen instead.

From your suggestion of a possible onboarding flow: the doctor creates his/her II and registers his/her doctor’s office in the same step (while logging in with the II).

Yes.

The backend canister returns a code (could be the unique office id created from the registration step above), which he then makes available to the front office users.

There should be a different code for each front-office user to be onboarded (and the codes should be single use).
Also, I would generate the codes in the front-end (in the doctor’s browser session) and only store the hash of it in the back-end. That way you avoid issues with regards to malicious replicas stealing the codes from the back-end.

The front office user creates his II, uses that and the access code to login. Is this a correct assumption?

The front office worker signs in to the application with the newly created II and the enters the code to associate that identity with the doctors office.

Is there a best / recommended practice vis a vis these kinds of workflows?

We don’t have specific best practices for that exact flow, but a section of more general ones here.

1 Like
5

thanks for sharing. very informative

1 Like
6

Thanks for your responses @frederikrothenberger. Very much appreciated!

Cheers

1 Like