10:44 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/09/2015 04:13 PM, Lucas Ponce wrote:
- We will have users associated by tenants, so a tuple (tenantId,
userId) should be unique i.e. (tenantA, userA), (tenantB, userA).
Not exactly. We'll have "users" and "organizations", a la github.
So,
no "tenants".
- A tuple (tenantId, userId) will have associated a list of roles
(with hierarchy like an organization ?).
Instead of roles, it's more likely that there will be permissions on
resources. For instance:
- - user jdoe belongs to "acme", and "acme" has read access to
"metric1". Therefore, jdoe has read access to "metric1". For this to
work, I'd need to be notified whenever a resource is created (probably
via the bus?).
- Metrics/Definitions/Resources should be unique by tenant, so our
backend should have something like (tenantId,
{metricId|resourceId|definitionId}).
A resource (metric, alert, ...) will have an "Owner", which can either
be an user or an organization. At this point, I think you won't need
to track the ownership of the resource, as I intend to track this on
my side.
- In the APIs, tenantId will be explicit nor implicit.
I think this needs a broader discussion, to get a consensus. I would
be happy with paths with resource IDs, without mentioning the owner:
"/metric/{metricId}", but I see also advantages in having
"/{owner}/metrics".
- Keycloak would be responsible to pass a (tenantId, userId) +
roles list to the component/application.
Not a tenant, but an user. But I don't think you'd need to have
explicit access to an user.
So, my main doubt is about how are we thinking to work with the
authorization, I guess that component backend should define some
authorization rules based on roles and permissions, right ?
I hope to have this very transparent to the individual components, but
I'll need to know the "resource" (ie: metric1) and the
"operation"
(ie: "read metric"). With that, I should be able to build a filter
that would automatically block the request if the user has no
permission to run the operation on the resource.
I guess that this part should be more or less shared for all
components.
Yes, that's the hawkular-accounts repository.
Is there any draft about it ?
Sort of. I'm building the basics of it right now:
https://github.com/hawkular/hawkular-accounts
I intend to make a service like this one available to the individual
components:
https://github.com/hawkular/hawkular-accounts/blob/master/backend/src/mai...
Perhaps this question is very early and it can be put on hold for
later, but just curious about it, as I would like to think in
possible impacts.
I hope to have something available soon to be consumed by other
components. But the above should give you a picture of what's planned.
If not, let me know :-)
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJU2OQHAAoJECKM1e+fkPrXeg0H/12/04nv8MGPK6XugdT/29kW
UYs/vmu0Ftd9nR5gwbQR7/goZu76bTGmfRUdijSR5d1lkO6JdHQ7kscHkjcPbWPc
bMMlWmWxkwyBu9XKa0D7a5s/6zURJkn1rQ/qFCvXbdIrqjFl5oKdpzes+BB4ZrW5
LeEKFuzHoeWlCTf/nDB0jz9c04PUMqrVzrHoq8iW+c92HWge7H6s3cS6qlfM1pQp
mMwcOCLHsMd2jiXAbpYw5tr+3fq7de9/8Fx8SmlPmow20ISii31lexi4MvUEYx/H
Kt2MbROqcY96yKu0edBzvPFs1GWFAYoZa7MRUyPCM02NaRzGwsJVXd0HyFNvtK4=
=btut
-----END PGP SIGNATURE-----