How to define AshAuthentication policy through a many_to_many relationship?

Just one note on terminology: policies and AshAuthentication are unrelated to each other. Authentication is “who is the user”, and Authorization is “what can the user do”. Authorization is built in to Ash core, but Authentication is done with something external to core (most often AshAuthentication).

One thing to note is to make sure that you’ve read through the policies guide. It can be hard to wrap your head around, but once it clicks you can do a lot of really cool things with them. And most people say they had to read it two or three times

Based on what you’re saying, I actually think there are two problems here.

Data model

If your data model is such that an actor has a role, i.e :team_lead as an attribute, and then relates to multiple teams, how could you have an actor that is a lead of one team but a member of another? Typically the role would exist in the team memberships. Then you could do something like this:

authorize_if exists(team_memberships, user_id == ^actor(:id) and role == :team_lead)

Policy flow

policy checks operate like a “workflow” where you step through each step in order. There are more options than just authorize_if. So if you are keeping your existing data model, then you are likely looking for something like this:

  policy action_type(:create) do
    authorize_if actor_attribute_equals(:role, :admin)

    forbid_if expr(not exists(team_memberships, user_id == ^actor(:id)))
    authorize_if actor_attribute_equals(:role, :team_lead)
  end

Good points of clarification – thanks for that. I think that was a typo, I should have typed AshAuthorization (not AshAuthentication). (I’ll update that for posterity).

I found the policies guide lacked some specifics, but the corresponding chapter in your book was helpful in clearing up some of the confusion. I do wish there was a more in-depth exploration of how to manipulate many-to-many relationships.

If your data model is such that an actor has a role, i.e :team_lead as an attribute, and then relates to multiple teams, how could you have an actor that is a lead of one team but a member of another? Typically the role would exist in the team memberships. Then you could do something like this:

Agreed, but in this business case it’s not a concern. I actually had a :role on the Members resource, but we removed it as unnecessary given the simple business case.

policy checks operate like a “workflow” where you step through each step in order. There are more options than just authorize_if. So if you are keeping your existing data model, then you are likely looking for something like this:

  policy action_type(:create) do
    authorize_if actor_attribute_equals(:role, :admin)

    forbid_if expr(not exists(team_memberships, user_id == ^actor(:id)))
    authorize_if actor_attribute_equals(:role, :team_lead)
  end

That is actually what I’m doing in the latest Team and it’s perfect for the Team API. But in this case I’m concerned about direct manipulation of the Member (the relationship)?

But it seems that I should prevent directly updating the relationship, e.g.,

  WasteWalk.Teams.Members |>
  Ash.Changeset.for_create(:create, %{user_id: u, team_id: t}) |>
  Ash.update!(actor: not_a_team_lead)

The only user that should be allowed to do that is a team lead. So, I’m trying to prevent updates on the relationship itself (here, Member). Keep in mind that’s the joining resource, not the Team itself. The join resource only has these relationships available:

# Member
  relationships do
    belongs_to :user, WasteWalk.Accounts.User, primary_key?: true, allow_nil?: false
    belongs_to :team, WasteWalk.Teams.Team, primary_key?: true, allow_nil?: false

    actions do
      defaults [:read, :destroy, update: :*]
    end

Is there a way the DSL does something like this, or is this totally custom? (From a DSL perspective, something kind of like this psuedocode):

# Member (the join between Team and User)
  policy action_type(:create) do
    authorize_if expr(
      exists(:team_id == ^team_id && :user_id == ^actor(:id))
    ) && actor_attribute_equals(:role, :team_lead)
  end

Otherwise, Members (the joining resource) is somewhat loosely secured. (Maybe it’s unnecessary? It’s not exposed over an API… I could be taking this too far, but it seems like the business rule should be validated on the joining resource).

I’d love to see more complex examples added to the docs / your book… most of the examples are a good start, but they seem to come up short of some real-world concerns, e.g., visibility / security scenarios. For example, being able to follow an artist is nifty, but in a business setting it important to model all the constraints… like, authorize a trade on certain accounts, viewing balances on others, no visibility if it’s a non-client account, plus security to make sure nobody could manipulate the system…

Yes, you can write:

  policy action_type(:create) do
    authorize_if expr(
      exists(:team_id == ^team_id && :user_id == ^actor(:id))
      and ^actor(:role) == :team_lead
    )
  end

But, if you actually step through the logic, the above code’s behavior is identical

to this ones:

  policy action_type(:create) do
    authorize_if actor_attribute_equals(:role, :admin)

    forbid_if expr(not exists(team_memberships, user_id == ^actor(:id)))
    authorize_if actor_attribute_equals(:role, :team_lead)
  end

Now, with all of that said, looking at your code with fresh eyes, we have a problem

You can’t use filter expressions like this on create actions. You’ll get an error if you tried. You’ll need to write a custom check.

An example can be seen here: Ash.Policy.SimpleCheck — ash v3.29.3

Custom checks may also be a nice tool if the policies flow is causing confusion, because they are “plain old Elixir”

Thank you @zachdaniel appreciate you taking the time to understand the question and confirm. I had suspected this would need to be custom… but wasn’t sure, as I really don’t know the policy DSL very well yet.