What is the recommended way to add an admin account in multi tenant setup?

Ash Forum Ash Questions / Help
, ,
1

Hi! I’ve just started using Ash due to its multitenancy capabilities. Overall experience is great so far, but I am considering following scenario right now.

  • there are multiple organizations, which data lives in separate schemas (context based multitenancy)
  • each organization has its own users and tokens tables
  • signing in is quite straightforward when current tenant is being fetched from subdomain

But what is the recommended way of adding admins right now? The only way I see is to create another resource called `Admin`, but what about AshAuthenticationPhoenix views and routes? If I’d use different strategies, the UI should be different. What about impersonation? Am I missing something?

3 Likes
2

Welcome to the forum!

I can’t answer your question, but for clarification when a more Ash-skilled person comes online, are you asking about tenant-admins (a role for a tenant user capable of doing more within an org) or cross-tenant admins (a login for a system operator to access cross-org controls)? From your question about impersonation, I’d assume the latter, though I have seen single-tenant admin impersonation before.

1 Like
3

I meant global admin that could manage all resources, impersonate users from different organizations and so on

1 Like
4

I think what you need is this i.e.

actions do  
  read :read_all_users do  
    multitenancy :bypass_all
  end  
end  
  
policies do  
  policy action([:read_all_user]) do  
    authorize_if actor_attribute(:global_admin?)  
  end

in the user resource. Then I think it’s a matter of fetching what you need for impersonation. Ash.Scope should come in handy! :flexed_biceps:

1 Like
5

Thank you for suggestion! Could you please provide more details about this approach? I’m not sure if that one aligns with the need of separate resources + authentication strategies. Since 2FA is not available right now (or I couldn’t find any resources on that) I’d like to go with magic links for admins and with regular passwords for normal users. I guess I need to use separate resources.

6

I don’t think you need separate resources, rather separate actions, the admin ones having admin authorization policy. By bypassing tenant logic on read actions you could fetch any and all organizations. You impersonate an organization by creating a session with relevant data from given organization/user.

So, you need an attribute to determine if an user is an admin or not. Based on that you can create policies. Based on that you can create actions with that policy and bypass mechanism to fetch across tenants. With those actions you should be able to get any data you need to create a session of impersonation for an admin. At least that’s how I see it; I haven’t tried, I might be missing something. :see_no_evil_monkey:

7

But since each organization has its own users table, where am I supposed to put “admins“ in this scenario?

8

@zachdaniel I guess I need your help :sweat_smile:

9

Just coming back from vacation. Also busier than ever :slight_smile:

Typically you would create a separate resource that uses ash_authentication just like your user resource, as per your first message.

This sort of thing can get complex because how you write your policy logic needs to handle cases where the actor is an %Admin{}. But we’ve done the same thing in my current application. For masquerading, we do that with magic links and a special action that generates a magic link with a custom claim set.

You can control using options in your auth routes what resources to add route for, so you can have like /admin/sign-in etc.

I’d suggest asking around in the discord/searching there if you don’t get what you’re looking for here.

2 Likes
10

Thank you Zach. I’ve gone through forum for implementation tips but couldn’t find any detailed enough. Your confirmation that this is right direction is really valuable :slight_smile:

11

I was referring to the discord server, not the forum.