> I believe that for a certain kind of resource - e.g.
> "we" manage
> we should not have the agent/feed supply the types, but Hawkular
> do so.
This can be the first capability that the agents can declare. Even
Which "this"? :)
nothing prevents anyone with enough permissions to create the
priori in the inventory. A glue component could listen on the bus and
sees a new tenant created, it can add the to-be-predefined resource
I would even go further and have that base WF8 type or whatever
be defined for the whole Hawkular system and not per tenant.
I.e. keeping that definition only once in the system.
If that is not possible, we can certainly have that listener install
it in each new tenant.
We already have a crude "proof-of-concept" of this way of
our "TemporaryHacks" class that adds the resource types needed for
In fact for more complex scenarios we not only need inventory
be populated "server side", but the feeds (hawkular-monitor) also
need to be able to consume this.
There is a question whether the glue component should be written in
way as TemporaryHacks - using low level API and circumventing any auth
Yes. I think so.
hawkular components or maybe by just really requiring every component
controlled access. I am for the latter even if it means more work
will provide the users with the ability to lock down the perms of
components which is good to minimize the impact in case of security
one of the distributed components.
There is certainly a point in this. Could we actually just shut down
a certain api inside inventory (for a certain caller)?
> For security relevant things we can not let the client/feed just
> type data, as otherwise it is too easy to work around checks.
This could be another agent capability - to support SSO - the auth
flow all the way down from the browser to the agent which would
operation as the user on the managed resource. Not sure how feasible
but it sounds nice ;)
Again: two things. We must not allow a malicious feed (i.e. one where
an attacker has modified resource type definitions to say "every one
can execute") to be uploaded in the server and then prevent any
RBAC checks inside the server.
The other part which you mention is certainly SSO and "run as" for
operations in the agent, which will allow WF to do its own security
checking instead of relying that Hawkular has everything
correctly set up.
> While it is possible for WildFly to obtain the security levels
> from the WildFly Metadata, we still need to find a good way to add
> 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.
If these constraints are configurable then I think resource type is
right place to have them. IMHO they would better fit into the
Right, if you see the combination of <role(user), WF_Operation> as
a runtime property of such a resource.
Certainly makes sense, but also makes things more complicated
That is probably the price for not running inside the target server
(like the WF-console).