[Hawkular-dev] Authorization flow

Juraci Paixão Kröhling jpkroehling at redhat.com
Mon Feb 9 11:44:56 EST 2015


-----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/main/java/org/hawkular/accounts/backend/boundary/PermissionChecker.java

> 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-----


More information about the hawkular-dev mailing list