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

Bill Burke 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 mailing list