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

[Pedro Igor Silva]

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
>