[keycloak-dev] [authz] introducing security holes by mistake
Pedro Igor Silva
psilva at redhat.com
Mon Mar 27 07:23:20 EDT 2017
On Sun, Mar 26, 2017 at 12:44 PM, Bill Burke <bburke at redhat.com> wrote:
> 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 understand your point. But I would prefer to avoid such constraints. If
you want to have multiple permissions for the same resource-scope pair you
should be able to do it.
I think there are other ways to address this like improving UI to show a
"Permission Graph", versioning of AuthZ settings, etc. I tried to address
this issue in some way when you click "Show Details" when listing
resources. There you can check it out all permissions applied to a
resource. The same for scopes ...
The evaluation tool also helps to check for situations like that. From
there you can see all permissions/policies evaluated for a resource/scope.
> 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.
The "Show Details" on resource listing does provide you something similar,
doesn't it ? I mean, from there you may check all permissions that are
associated with a resource (even if not associated directly like when using
a scope-based permission).
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
More information about the keycloak-dev