[keycloak-dev] [authz] introducing security holes by mistake
bburke at redhat.com
Sun Mar 26 11:44:56 EDT 2017
In Authz you can define a permission that applies only to scope or only
to resource or only to a specific resource type. These are different
ways to define default behaviors. Also, you can define multiple
permission definitions for the same scope, resource, or combination of
both. You can do this multiple times.
This bring me to the point of this email. Isn't it too easy to screw
things up? Somebody could add a more constrained permission that
overrides default behavior and not realize that they've screwed things
up. Somebody could add an additional permission for a resource and not
realize there was already an existing one. It all seems very error prone.
I'm wondering if we should constrain this a bit more. For instance,
what if each resource-scope pair is unique? That is, you can't define
more than one permission for each resource-scope pair. This goes for
resource only, resource type only, and scope only permission definitions
too. That way, when somebody goes to define a permission, they see all
policies that are currently applied.
I also think that any resource-scope permission definition should
automatically inherit from permissions defined in resource-type,
resource, or pure-scope permission definitions. You should see these
inherited permissions in the "Applied Policies" when you create the
resource-scope permission. Then admins can remove the inherited
permissions they want to.
More information about the keycloak-dev