4:06 a.m.
Hey,
one thing that we did not touch yet, but we probably should are user roles and their
permissions.
The driver for me here is that the current rhq-metrics rest api offers endpoints to upload
and retrieve (metric) data,
but also to modify (meta)meta data like the retention period of metrics. This is something
I consider as more
restrictive, as you don't want arbitrary feeds to just set the retention period to
10years without anyone noticing.
There are probably other endpoints (in existing rhq-metrics) that need more elevated
rights as well.
Same applies of course for the more overall Hawkular project.
We are trying to (conceptually) align with what WildFly offers (at least on the role
side), so that users who know one, also feel at home with the other. There are obvious
differences though with what RHQ has been offering for a long time (even before AS7).
Not only from the fact that expect to "superuser" no roles are built in, but
also in the fact that the assignment of role to resource is not "direct", but
done via resource groups, that can be composed on the fly.
See e.g. the first part of
https://developer.jboss.org/community/rhq/next/blog/2014/11/11/thoughts-o...
for a quick intro into that.
Current RHQ RBAC also has shortcomings where the WildFly one is better (and still, there
may be some more fine grained permissions needed). E.g. we have so called
"operations" (a lot like the operations on WildFly resources), where we are not
able to differentiate between "harmless" show-xyz operations and more sensitive
"reboot box X" ones
From Brian Stansberry:
---
WildFly RBAC isn't heavily based on resource assignment. It's about assigning
different constraints to roles and then providing information about the actions users want
to take and the resource/attribute/operation involved and seeing if the constraints are
met.
The answers as to whether a constraint is violated don't generally fall along resource
lines. The main constraints:
1) Is it a read or a write. Presumably dealing this kind of thing won't be an issue
with any authorization scheme. :)
2) Does a write affect persistent configuration? This often depends on the particular
attribute/operation, not the resource. Perhaps it's not so critical though.
3) Is the resource/attribute/operation configured as security sensitive? This is the key
one and it doesn't map cleanly to resource assignment, since individual attributes can
be sensitive while the overall resource is not, and different classifications of security
sensitive can differ as to whether reads and writes are both sensitive, or just writes.
---
Anyway: we need to start tagging endpoints with information about access levels so that we
can enforce them by different policies. Those policies should probably not only take the
user + credentials into account, but also the origin of requests, as for the above
example, a request coming from the same machine or e.g. the Hawkular-glue may be treated
differently than one coming from some random dump feed on the internet.
Note, that those access levels usually do not replace authentication (via KeyCloak), but
are applied after successful authentication and probably role assignment.
Depending on the use case (embedded Hawkular-metrics, Standalone Hawkular-Metrics,
Standalone Hawkular) the
check points may be at different places, or we decide to e.g. always enforce at the
component boundary.
The following two drawings should illustrate this
The green circle illustrates the "check being at java-level" on the standalone
side,
which also would still work for the embedded case when the rest-api is replaced
by some other implementation.
For the Hawkular server, we could move the check earlier e.g at the message-gw.
Or just pass the additional information (origin, ...) on the message on the bus and
then keep the checks at Hawkular-metrics core as in above case.
Heiko
