[keycloak-user] Migrating existing system vs. resource mangement

Tue May 9 09:32:02 EDT 2017

Thanks a lot for your prompt response Pedro and for confirming our
understanding.

Do you have opened issues that would describe what "supporting a better
contextual access control" would translate into, and that we can also vote
on it?

This seems to be the missing bit that probably will make us reconsider
Keycloak for the moment. Having policies that require knowledge about the
resources' attributes, other than the resource owner, is a fundamental
piece of the policies we would like to implement. Even if we did go through
the process of first pushing all our resources to Keycloak and keeping them
in-sync afterwards, we'd still need to access more than just the resource's
owner in our policies. From what I understand, this ins't possible at the
moment, and this could be solved with those contextual access control
improvements.

We thought this would already be covered because we considered that a
pretty "standard" need, but the fact that this isn't currently possible
makes us wonder: is this in the scope of what UMA is trying to address?
Take the following policy for instance (pseudo code):

rule "Expensive Product"
    when
       $evaluation : Evaluation($permission.resource != null &&
$permission.resource.price > 100.00)
    then
        $evaluation.grant();
end

Should this exist as a Keycloak policy? Should it know that our "product"
resource has a "price" attribute and that we have policies that depend on
it?

What we're also trying to address as a problem is to have a central
repository of where our security policies are defined (in whole) so that
it's easier to audit, review and maintain them. If we can't have such
policies defined because it's not in the scope of what is supposed to be
covered by Keycloak (or other authorization servers for that matters), then
we'd be forced to distribute the authorization process between Keycloak and
some other service. And because of that, we wouldn't have all the rules
required to resolve a policy in a single location.

Does that make sense?

Thanks!

On Tue, May 9, 2017 at 8:03 AM Pedro Igor Silva <psilva at redhat.com> wrote:

> Hello Yannick,
>
> Starting from the bottom ...
>
> Right now, policy evaluation is solely based on the resources you have in
> Keycloak. So yes, you would need to use the Protection API to manage your
> resources every time you create/remove them from your application.
>
> I understand your concern about "maintaining duplicates" of resources.
> However, authorization services is strongly based on UMA concepts and there
> the AS plays an important role when managing the resources belonging to
> your users. By having complete control over resource owner's resources, the
> AS is capable of managing and taking care of these resources for your users
> (and your application) so you benefit from everything the AS provides such
> as privacy control, permission management and resource sharing, things that
> are very closely related with the basis of UMA: user managed access.
>
> What you described as "provide arbitrary attributes" is exactly what we
> are looking for. So you would have a more "stateless" permissioning model
> where you don't really want Keycloak to manage your resources, but just
> provide "facts" to the policy engine and have them processed by any
> matching policy in order to get a decision. This feature is pretty close
> related with a better contextual access control support. As it stands
> today, the "context" is basically what you have in your access token and
> you are not able to send any additional information.
>
> Back to "maintaining duplicates" topic, some time ago Bill Burke suggested
> a very interesting approach to resource management and storage. He
> suggested that we could provide a "Resource Provider SPI" that users could
> implement in order to fetch resources from an external database. I think is
> another thing we would start working for the next release.
>
> On Tue, May 9, 2017 at 7:30 AM, Yannick Lazzari <yannick.lazzari at gmail.com
> > wrote:
>
>> Hi,
>>
>> We're currently evaluating Keycloak to migrate an existing system. For the
>> sake of the discussion, let's use the photoz example and pretend we are an
>> online pictures hosting service and that we have millions of albums,
>> belonging to thousands of users (users typically have more than one album,
>> so we have more albums than users).
>>
>> If we were to implement the same permissions and wanted to constraint the
>> deletion of an album to its owner, does that mean that we would first need
>> to "sync" all our existing albums in Keycloak by "pushing" a
>> ResourceRepresentation for each of them, so that we can then have a policy
>> that uses the owner?
>>
>> And what if we actually have dozens of other resource types for which we
>> want to enforce similar "resource owner" policies, each of them having
>> millions of records and living in different databases? Is it also expected
>> for all of them to do the same, essentially maintaining duplicates (in
>> some
>> form) of all existing records in our system inside Keycloak's single
>> database, just so that we can use the resource owner in some policies?
>>
>> We understand the simple photoz example, for something that starts from
>> scratch and with little data, but we have a hard time seeing how such an
>> approach can scale well for an existing system with millions of resources
>> of different types. Or perhaps we're completely missing the point or an
>> important piece of the puzzle.
>>
>> Instead of having to push resources to Keycloak, is there a way to provide
>> arbitrary attributes that would be stored in the evaluation context of
>> policies and made available for the duration of a single authorization
>> request? For instance, when authorizing access to /album/123, could we
>> tell
>> Keycloak that the owner of this album is actually user id 456, have it
>> stored in some attribute in the evaluation context and then use that
>> attribute in a policy (whether it's Javascript or Drools), along with some
>> other arbitrary attributes? We've seen discussions around the usage of
>> custom user claims, but this does not really seem to apply here since
>> those
>> are not resource-specific. Or would there be a way to "extend" Keycloak
>> and
>> use a hook that is provided that would allow us to somehow add this
>> information to the evaluation context?
>>
>> Looking for help to see how we would start tackling such a problem, if we
>> were to adopt Keycloak.
>>
>> Thank you very much for any insight anyone can provide!
>>
>> Yannick
>>
> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>