5:30 a.m.
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
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
8:32 a.m.
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(a)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(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
>
2576
days inactive
2576
days old
2 comments
2 participants
participants (2)
-
Pedro Igor Silva -
Yannick Lazzari