Brian Stansberry [
https://community.jboss.org/people/brian.stansberry] commented on the
document
"Access control notes"
To view all comments on this document, visit:
https://community.jboss.org/docs/DOC-48596#comment-11920
--------------------------------------------------
In the general tasks section there are a couple of lines mentioning
"Enforce Permissions" in web console and CLI - I would suggest there should be
no mention on client side enforcement as that is just not enforcement - all of that needs
to be on the server side.
Agreed; we need another term.
This in turn implies to me that anything server side needs to be more than just
enforcement i.e. performing an authorization check at the time of an attempt to access the
model / execute an operation is the bare minimum - we potentially need to be able to go
beyond this to pro-actively identify what can or can not be accessed.
As we have mentioned previously for any permissions schema to be secure it needs to be
understandable, one possibility here is to look at ways to show the effect of the
currently defined permissions scheme on the domain model. This could be something along
the lines of generating a report which visualises the tree and highlights what can and can
not be accessed by a specific user / role - alternatively social networks commonly have a
view profile as option to see what others can see, this could be a mode to consider in the
console.
Some of these items might be out of scope for this phase of development but just wanted
to raise them so we can at least take them into account.
This is what I was getting at with
read-resource-access op (an op to learn about user's ability to use API; based on
read-resource-description)
+ uses
++ general information
++ allow caller to disable features that will be non-functional (e.g. buttons for misc ops
that are not available)
My assumption is the admin console will need something like this to provide a proper UI.
If it does a read-resource, a response header associated with the response can indicate
that certain attributes or children were filtered out due to access control reasons, so
the console can take action when it renders the screen. But to know that the "Test
JDBC Connection" button should be disabled or hidden, the console will need to know
that the op is not allowed, and that won't come from any existing op.
The report thing you mention could be a twist on this with parameter(s) to set the
"view as" value. Perhaps a different op but with shared implementation details.
--------------------------------------------------