[keycloak-dev] [authz] introducing security holes by mistake

[Pedro Igor Silva]

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


>
> Bill
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>