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’.

I created a library a little while back called Access Decision Manager. I think it might do what you’re looking for. It’s based on logic by the same name in PHP’s Symfony framework. Quick examples:

granted?(viewer, "CREATE_FOO", some_entity) # true / false

This uses a “voter” system that allows for per-entity permissions. You can also use it for simpler scenarios like this:

granted?(viewer, "ROLE_SUPER_ADMIN")

This is where the “subject” and “entity” are the same (eg. you want to know if the viewer has the super admin role).

We’re currently using this in production, in both Guardian plugs, as well as Absinthe resolvers. Slightly paired back resolver example:

def update(%{input: %{id: floor_plan_id}}, %{context: %{viewer: viewer}}) do
    case FloorPlan.get(floor_plan_id) do  
      %FloorPlan{} = floor_plan ->
        if granted?(viewer, "EDIT_FLOOR_PLAN", floor_plan.project) do
          # ... update floor plan

        else
          {:error, message: "Permission denied.", code: 403}
        end

      nil ->
        {:error, message: "Floor Plan doesn't exist.", code: 404}
    end
  end

For note, ueberauth integration is not needed at all. ueberauth is an authentication library, not an authorization, and thus its purview ends where terminators begins.

Overall, a lot to take in here. I wouldn’t really use roles as I do detailed testing on everything, so perhaps an example. Right now I do a lot of checks like this:

    conn
    |> can(%Permissions.AH.Requirement{action: :edit, tag: ah_tag, id: id, pidm: pidm})
    ~> case do conn ->
      # Do stuff...

      records =
        Something.get_records(...)
        |> Enum.filter(&can?(conn, %Permissions.AH.Requirement{action: :edit, tag: ah_tag, id: id, pidm: pidm, record: &1.name}))

      # Do more stuff...
    end

Where can/2 takes an environment (whether a conn, channel socket, token, etc…) and an ‘ability’ structure (to use a terminator term, just called a ‘permission’ here) and it returns either the environment back out (possible modified with cache data if allowed, but in general I use Cachex a lot instead) or it returns an exception structure (which is what the ~> is handling via the exceptional library, but that can be easily tested anyway), or I can use can?/2, which is the same but returns true/false.

In the admin interface all permission structures are listed in every account that can be added/removed/modified on a key-by-key basis. When an environment is looked up it’s permission data for the specific account is looked up in the database as well as the permissions for the groups and then they are merged in a way that works for my permissions_ex library (everything is either Allow/NotAllowed/Deny where not defined means NotAllowed and Allow overrides NotAllowed to allow but Deny overrides all others to always Deny regardless of all other settings).

But the above example tests if the current user has access to the AH Requirement of the proper tag, ID and for the PIDM record then filters the specific record names that the user has access to before proceeding. I use lots and lots of these checks everywhere and can is very well optimized for lots of use (a cache, database sends an event when permissions updated, etc… etc…). How would this pattern be done in terminator? I’m having an interesting time understanding the README.md, like is load_and_authorize_performer a magic function that does something, what do the permissions and as_authorized blocks actually do, how does it handle permission failure (like in my system an exception causes the system to redirect to the login page along with a message saying what permission they failed and to log in to an account that has such a permission for example), etc…? The ‘abilities’ in my system are hard-coded (it makes no sense to make them dynamic as the functionality everywhere only uses what it knows anyway, thus they are structs that the system can gather a list of via behaviour implementations).