Hello Koloman,
As you may have noticed, I have sent a PR with some fixes and improvements
to the policy evaluation engine.
I've used your repository to test things out and I only have one comment.
There you have a resource-c which is granted by a resource-based permission
and for this resource you will be granted with all scopes associated with
the resource. Differently than resource-a, where you have only a
scope-resource permission for a specific scope, which does not imply
granting additional scopes.
If you want to provide more fine-grained permissions to the scopes
associated with resource-c, you can define scope permissions to the scopes
you want to protect.
I think I'm going to review the ENFORCING mode for 3.0 in order to also
include "orphan" scopes when evaluation policies. This may bring some
usability issues as a consequence of a more restrictive permissioning
model. Or we can create a separated enforcement mode for this kind of
stuff, maybe a configuration option on a resource permission, I don't know
....
Regards.
Pedro Igor
On Thu, Mar 9, 2017 at 1:34 PM, Pedro Igor Silva <psilva(a)redhat.com> wrote:
On Thu, Mar 9, 2017 at 11:58 AM, KLIMPFINGER Koloman
<Koloman.KLIMPFINGER@
frequentis.com> wrote:
> Hi keycloak users!
>
> I've a question about using scope and resource permissions to protect my
> resources.
> To me it seems that keycloak is granting broader authorization
> entitlements than I specified it with the policies & permissions - a
> security issue from my point of view.
> For example keycloak - according to the entitlement token of a user -
> grants access to a resource and ALL its scopes, even if I only specified a
> permission to access only ONE scope on that resource for that user (with a
> policy).
> Is It wrong to assume that the user should only have access to the one
> scope?
Another issue is that keycloak grants access to a resource and ALL its
> scopes, even if I only specified a permission to access only that resource
> for that user (with a policy) without a scope.
> Is the assumption wrong that the user should only know about the resource
> but not the scopes?
>
> Or is my understanding of how to handle the authorization entitlements
> for resources and their scopes with keycloak wrong?
> What would be the best practice to secure the resources and their scopes?
>
You are correct. This is an issue with the Entitlement API and Scope-based
Permissions. Created
https://issues.jboss.org/browse/KEYCLOAK-4555,
sending a fix shortly.
You should not see this happening if using Authorization API where
evaluation is performed on a per-resource/scope basis.
Will take a look on that repository (just perfect to understand what is
happening) you pointed out and check the results once I have the issue
fixed. Can you watch that JIRA for updates ?
>
> Here I describe the scenario & point to a live example:
>
> _ The scenario _
>
> Created Entities:
> User: Marta
> Policy: Policy-IsUser-Marta
> Scopes: read, write, execute
> Resource: resource-a (with all three scopes)
> Resource: resource-c (with all three scopes)
> Resource-Permission: resource-c -> Policy-IsUser-Marta
> Scope-Permission: resource-a + scope read -> Policy-IsUser-Marta
>
> Retrieve entitlements:
> Get your (Martas) entitlements token and check the granted permissions -
> they are:
>
> - resource-a -> read + write + execute
>
> - resource-c -> read + write + execute
>
> What I would expect:
>
> - resource-a -> read
>
> - resource-c -> (no scopes)
>
> _ Sample Project _
> I created a sample to see it live in action:
>
https://github.com/kklimpfi/keycloak-scenarios
>
> It contains a keycloak-migration.json with some sample data (in master
> realm) + an java application that retrieves the Permissions.
> you can clone it and try it (configure setup script for importing and
> pass the system property for the java application to its configuration).
> (Using Keycloak-2.5.4.Final standalone on Windows 7, should also work on
> Linux)
>
> kind regards,
> Koloman
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>