Re: [keycloak-dev] [authz] introducing security holes by mistake
On Sun, Mar 26, 2017 at 12:44 PM, Bill Burke <bburke(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev