7:03 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user