[Hawkular-dev] Resourcetype again

[Heiko W.Rupp]

Hey,

we have said that we do no longer want the very strict resource types 
that
we had in RHQ. We also identified that we need resource types to define
capabilities like metric types with their units etc. The newest addition 
now
are operations and resource config.

I believe that for a certain kind of resource - e.g. "WildFly 8.2", that 
"we" manage
we should not have the agent/feed supply the types, but Hawkular should 
do so.
A user may still decide to extend that to supply its own data, but we 
need to be
careful when dealing with it.

For security relevant things we can not let the client/feed just provide 
resource
type data, as otherwise it is too easy to work around checks.

For WildFly there are a bunch of RBAC roles [1,2] that need to map to 
what
we (will) have in Hawkular, which we may define as just what WildFly 
has.
In fact that will be beneficial, as users will already know how WildFly 
RBAC works
and can apply it to Hawkular. Plus if the user already has its org 
members in
a central KeyCloak with role mappings, we can hook up to that instance
and get the mappings "for free".

Now for operations on WildFly (not only the classic RHQ-operations, but 
also modifying
resource config), RBAC in WildFly is "hiding" whole sub-trees, but also 
(iiuc) individual attributes
if you do not have the right role:

role=SuperUser:

[standalone at localhost:9990 /] cd /core-service=management/access
[standalone at localhost:9990 access] ls
audit          authorization

role=Monitor:

[standalone at localhost:9990 /] cd /core-service=management/access
[standalone at localhost:9990 access] ls
audit

With enough privileges it is possible to see the access definitions
under /core-service=management/access=authorization/constraint=*

While it is possible for WildFly to obtain the security levels 
(automatically)
from the WildFly Metadata, we still need to find a good way to add this 
information
into our resource types, as the UI may need to react to them and not 
show a
restart button for user that only has the Monitoring role. In theory we 
could
just issue the operation with the user perms and see it fail on WildFly 
side, but that
is certainly not user-friendly and thus not desired.

For other kinds of resource like Tomcat we probably need to encode the 
roles
to the best of our knowledge.

   Heiko


[1] http://blog.arungupta.me/role-based-access-control-wildfly-8/
[2] http://www.dzone.com/articles/configuring-rbac-jboss-eap-and