I have some found problems/questions related to your READM.md file …

#1 Missing do keyword at line 1:
defmodule Sample.Post → defmodule Sample.Post do

#2 Wrong module call at line 20:
Sample.Repo.get(Sample.Post, id) |> Sample.repo.delete() → Sample.Repo.get(Sample.Post, id) |> Sample.Repo.delete()

#3 Wrong module call at line 26:
:ok -> Sample.Repo.get(Sample.Post, id) |> Sample.repo.delete() > :ok -> Sample.Repo.get(Sample.Post, id) |> Sample.Repo.delete()

#4 Firstly you give example:

    permissions do
      has_role(:admin) # or
      has_role(:editor) # or
      has_ability(:delete_posts) # or
    end

and then you give this one:

    permissions do
      calculated(:confirmed_email)
      calculated(:is_owner, [post])
    end

so it will succeed when owner of specified Post does not had confirmed email, right? It does not looks like a perfect example here

#5 Another problem is in this example:

defmodule Sample.Post do
  def create() do
    user = Sample.Repo.get(Sample.User, 1)
    post = %Post{owner_id: 1}
    load_and_authorize_performer(user)

    permissions do
      has_role(:editor)
    end

    as_authorized do
      case is_owner(performer, post) do
        :ok -> ...
        {:error, message} -> ...
      end
    end
  end

  def is_owner(performer, post) do
    load_and_authorize_performer(performer)

    permissions do
      calculated(fn p, [post] ->
        p.id == post.owner_id
      end)
    end

    is_authorized?
  end
end

Here performer in case statement is completely magic. Newbies would not get how it’s actually working.

#6 Also as_authorized do … case … end looks too complicated comparing to or examples.

Personally I would suggest some compile time scenarios like:

defmodule Example.MyModel do
  def_scenario :scenario_id do
    abilities([…])
    roles([…])
  end

  def_scenario :another_scenario_id do
    any_of(abilities: […], roles: […], scenarios: […]) # and
    all(abilities: […], roles: […], scenarios: […])
  end
end

and use it in with like:

defmodule Example do
  def sample(post_id, user_id) do
    with user <- Sample.Repo.get(Sample.User, 1),
      performer <- load_and_authorize_performer(user),
      :ok <- validate_scenario(performer, :scenario_name), # and
      :ok <- validate_role(performer, :role_name), # and
      :ok <- validate_ability(performer, :ability_name) do
      # here goes contents of `:ok` case result
    end
  end
end

What to do when you have performer User which is in Company in many to many relation? When you have function like def is_owner(performer, post) do … end there is no way to read company or company_id.

#7 Session plug to get current_user

Again, what if you have authorization based on multiple models?

#8 Will you provide any way to solve dynamic ecto queries?
Let’s say that somehow you have received not trusted generated ecto query which you want to validate, but you do not want to fetch millions of records. Instead you want to validate it properly on database level. Maybe there should be something like:

defmodule Example.MyModel do
  def_auth_check(user_id) do
    ensure_join(…, args: [user_id]) # join args here
    # continue ensure_join(…) in other models until reaching final model
  end
end

defmodule Example.MyFinalModel do
  def_auth_check(user_id) do
    ensure_join(…, as: :joined_name, …, on: [id: ^user_id]) # join args here
  end
end

defmodule Example.MyAuthModel do
  def_auth_check do
    check_ability(:read)
    # this would filter everything which in any depth joins this model
  end
end
# this is of course example written in "5 min"

In short I believe that there could be such changes:

1. More compile-time data - limit run-time for calculated functions which would be called manually anyway.
2. Think about some way to validate ecto queries without fetching records (as a second way - of course doing it for delete as you show is also good, but think about typical get and list REST API)
3. Consider remove some “magic” in order to have library which could be faster to understand for everyone
4. Consider making API more easy for and checks - not only for or cases

Let me know what do you think about it.

Awesome feedback! Yes your points are valid, I was also thinking about AND rules, either to introduce some terminating words or signatures like :next or :stop but your any_of and all is looking good. It’s good example as you can have defined more scenarios and validate only those which are needed inside function. I love it actually.

I will fix README.md

#7 I didn’t get the question “authorization” based on multiple models" do you mean that you have for example User → Company but both user and company are performers ?

#8 Understood makes sense, but for now I didn’t run to such case, but nice thing to put in roadmap

Again really thank you for your feedback, sometimes is really hard when you work on something too long, everything seems “obvious”, now I see where it is missing more clarity. Thank you! I will definitely implement something like scenarios. I like it.

That would only be for the specific account that was auth’d. The user should always convert that to some local ID that multiple sources all reify into, otherwise you get a set of disparate accounts.

Does that mean it hits the database on every request?

Where does it cache the information for the authorize calls? Hmm, looks like it uses an ETS table. I’m not seeing where it gets cleared out, will this table infinitely fill up to the unique ID count (I have a few tens of thousands of accounts in my system of which most are not logged in at a time except occasional times where ‘most’ of them log in within a short time period). Is it never purged over time?

I go a different route where instead of ‘abilities’ like edit+ah+record+pidm+etc I combine those into a singular record. This means that I have full knowledge of every possible combination at compile-time for the admin view (and others) generation. Thus I generally only test a singular ‘ability’/permission at a time. I guess mine kind of combine your ability/role into a singular well-typed unit.

Hmm, it looks like every authorization check hits ETS quite a number of times, how well is that handled with filtering out records that a user should not be able to see, it seems like it would cause a bit of a slowdown?

That’s what my groups are for, there is a many<->many account<->group binding in the database, and both accounts and groups have permission set, which get aggregated together appropriately (in the database layer actually).

I have a few tens of thousands of account (actually I can check, hold on… 18054, there should be about 30k but that means a lot of people aren’t logging in that should be logging in as the accounts are created on first access ^.^), with a few dozen permissions (each permission covers a HUGE range of access capabilities as they are configurable).

My specific use-case is a college if you are curious, I write the backend system.

Eh, it’s a very tiny library, I just wanted something rock solid with a minimal feature set that I needed. You could certainly do something better for something more specific to the user-case. That is the library that my permission matching is built on though.

I never released my overarching system that uses it though because I’m not happy with it, not the design or use, but I just can’t seem to come up with something better. It’s efficient enough that my server is the fastest of all that we have so I haven’t worried too much about that even during heavy load times, and the configurable permission structures have covered every case I’ve needed so far (and a great deal more), so I haven’t felt the need to try to iterate further on it.

For note, I’m poking at this because I’d really really want to see it replace my system. The less I have to manage and keep up to date myself, the better. I’ve also been very unhappy at all the other authorization frameworks I’ve seen in Elixir as well (this is something java does really well…).

EDIT: Oh, and another note, mine also pulls permission data from other servers as well, not just the database, but also a LDAP and CAS systems so any replacement I use needs to be able to have pluggable ‘stores’.