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