lock

lock copied to clipboard

We have a role system whereby denial is always more important than an allow.

1. A user can be assigned to many roles
2. Each role has a number of resources and permissions
3. Each permission has an allow/inherit/deny set of permissions.
4. Inherit means basically do nothing
5. Allow is only allowed if no deny is specified on any other roles for that action/resource

How can we implement this using lock?

1. A user should implement the BeatSwitch\Lock\Callers\Caller interface. The getCallerRoles returns the user's roles as an array of string keys or as an array of BeatSwitch\Lock\Roles\Role instances. You implement the assigning of the roles to the user yourself.
2. Assigning of permissions to roles is as easy as $manager->role('editor')->allow($action, $resource).
3. I'm not really sure how you see permissions inheriting other permissions. That's not possible in Lock. Roles can inherit other roles, for example, an admin can inherit all default editor permissions. I also plan to implement Resource inheritance: #24. Can you perhaps clarify more what you mean?
4. see 3.
5. That's basically how Lock works atm. If a deny is present then the action isn't allowed. I suggest you look at the tests to get a better view at how permissions are validated. If you think that some of the behavior isn't correct then please by all means let me know! I'm welcoming every opinion on this to improve Lock's behavior when checking permissions. There's an issue for this: #7

I'm sorry if I don't seem much active lately for Lock. Work's been hectic. Hopefully I can find some time soon to improve Lock even further.

@driesvints cheers for your input.

Basically a user could be assigned to many roles, and role X may allow a particular permission, whereas Role Y denies that permission, and Role Z inherits. Think of inherit in this case as a "pass-through", aka: ignore. Denial is very important though - even if role X allows it, role Y specifically denies that permission, so that takes precedence.

I'm trying to figure out how to do this with lock. Managing of permissions we're already doing, so don't need that aspect of it.

Last question - Authority allowed for the ability to provide functions as arguments for permissions checks iirc, which meant you could do some pretty funky stuff for allowing/denying permissions. Is this possible with Lock?

@driesvints I can see that here: https://github.com/BeatSwitch/lock/blob/master/src/Tests/PersistentDriverTestCase.php#L85 the test shows allow, then deny - therefore, denied. What if a second allow is added after that initial deny permission is set? What is the behaviour here?

With authority, this meant that the permission was allowed. That is not what we want at all.

@driesvints ping!

@kirkbushell I'll try to get back to you somewhere this week. I'm really sorry it's taking this long, I'm just too caught up in too much stuff atm.

Why not create a system where you choose if the more permissive win or not.

You can set that on the configuration file:

return [

    'order' => 'permissive',

];

Then...

"permissive" => if (true || false) -> true
"not permissive" => if (true && false) -> false

I'm just gonna be honest with you @kirkbushell. I don't have the time atm to look into this and probably won't have for the upcoming weeks. Lock is currently very low on my todo list.

@driesvints @kirkbushell even if currently Lock is not so actively developed, I think the architecture itself is the most usable one of the currently available implementations. So even if there are glitches (which you can just fix for yourself until there is an official solution) Lock is very promising and it worth waiting for it.

@sagikazarmark it wasn't really about glitches, but really how we needed to use auth. We ended up writing our own system in less than an hour.