Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parametrized Action / Ternary authorization #1646

Open
Yifferpi opened this issue Nov 10, 2022 · 2 comments
Open

Parametrized Action / Ternary authorization #1646

Yifferpi opened this issue Nov 10, 2022 · 2 comments

Comments

@Yifferpi
Copy link

Hi,

I have an authorization scenario which I find myself unable to implement, and the documentation / tutorials on the docs.osohq website don't seem to mention such a scenario at all:

I have an Event class with attendees, and some of the attendees are managers. The troublesome case is the following: Managers of an Event can remove attendees unless the attendee to be removed is another manager.
has_permission(p: Person, "remove", e: Event)` where p is the actor, does not do it because the person to be removed is not referenced. The problem is that the action must be of type string.

What is the typical way to handle such a policy? It seems to be common enough.

Some additional thoughts I explored:

  • adding oso.authorize(current_user, "remove_attendee", event) and `oso.authorize(current_user, "remove_attendee", attendee) as separate enforcement checks does not suffice.
  • adding a Relation during class registration does not help either. It might give us access to the list of managers of the event, but the relevant parameter (namely which attendee we are trying to remove) is still missing.

Is this scenario not enforceable with the current API of strictly only string-type actions or have I overlooked something in the documentation? If it is possible, an example in the tutorials would probably be great, since this type of access policy is probably fairly common.

Thanks for commenting

@samscott89
Copy link
Member

samscott89 commented Nov 10, 2022

Hey @Yifferpi!

You're right, an example would be a good idea, because this is indeed a pretty common scenario.

The way I would think about handling that is as a mutation of an EventAttendee resource. E.g. oso.authorize(current_user, "delete", event_attendee).

The EventAttendee resource could potentially correspond to a through table like event <-> event_attendees <-> user, or if that's not something exposed in your model, then perhaps you could create a small class to encapsulate that logic?

In any case, to me that most closely matches the semantics of what you're asking -- more granular than "can the user remove attendees (generically) from the event", it's, "can the user remove this specific event attendee".

How does that sound to you? do you think that would be feasible?

@Yifferpi
Copy link
Author

The container class EventAttendee sounds like a decently elegant solution to me and should work in my case :) Thanks for very much for commenting. Hoping to see the example in the tutorials some time in the future :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants