<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hey,<div class=""><br class=""></div><div class="">one thing that we did not touch yet, but we probably should are user roles and their permissions.</div><div class=""><br class=""></div><div class="">The driver for me here is that the current rhq-metrics rest api offers endpoints to upload and retrieve (metric) data,</div><div class="">but also to modify (meta)meta data like the retention period of metrics. This is something I consider as more</div><div class="">restrictive, as you don't want arbitrary feeds to just set the retention period to 10years without anyone noticing.</div><div class="">There are probably other endpoints (in existing rhq-metrics) that need more elevated rights as well.</div><div class="">Same applies of course for the more overall Hawkular project.</div><div class=""><br class=""></div><div class="">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).</div><div class="">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.<br class="">See e.g. the first part of <a href="https://developer.jboss.org/community/rhq/next/blog/2014/11/11/thoughts-on-tenants-for-rhqnext" class="">https://developer.jboss.org/community/rhq/next/blog/2014/11/11/thoughts-on-tenants-for-rhqnext</a> for a quick intro into that.<br class="">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<br class=""></div><div class="">able to differentiate between "harmless" show-xyz operations and more sensitive "reboot box X" ones</div><div class=""><br class=""></div><div class="">From Brian Stansberry:</div><div class="">---</div><div class="">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.<br class=""><br class="">The answers as to whether a constraint is violated don't generally fall along resource lines. The main constraints:<br class=""><br class="">1) Is it a read or a write. Presumably dealing this kind of thing won't be an issue with any authorization scheme. :)<br class=""><br class="">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.<br class=""><br class="">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.<br class=""></div><div class="">---</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Note, that those access levels usually do not replace authentication (via KeyCloak), but are applied after successful authentication and probably role assignment.</div><div class="">Depending on the use case (embedded Hawkular-metrics, Standalone Hawkular-Metrics, Standalone Hawkular) the</div><div class="">check points may be at different places, or we decide to e.g. always enforce at the component boundary.</div><div class=""><br class=""></div><div class="">The following two drawings should illustrate this</div><div class=""><br class=""></div><div class=""><img height="167" width="468" apple-width="yes" apple-height="yes" apple-inline="yes" id="01492D7A-21DA-4712-BDF4-557AEF37444B" src="cid:89813C34-EE8D-4AFD-9869-6609CC7D7AAA" class=""></div><div class=""><br class=""></div><div class="">The green circle illustrates the "check being at java-level" on the standalone side,</div><div class="">which also would still work for the embedded case when the rest-api is replaced</div><div class="">by some other implementation.</div><div class=""><br class=""></div><div class=""><img height="212" width="472" apple-width="yes" apple-height="yes" apple-inline="yes" id="E7005D76-215A-4B1F-BE6B-187E18135D09" src="cid:A0AC20C3-9914-475E-8005-C0380E133EC8" class=""></div><div class=""><br class=""></div><div class="">For the Hawkular server, we could move the check earlier e.g at the message-gw.</div><div class="">Or just pass the additional information (origin, ...) on the message on the bus and </div><div class="">then keep the checks at Hawkular-metrics core as in above case.</div><div class=""><br class=""></div><div class=""> Heiko</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>