[jboss-dev-forums] [JBoss AS 7 Development] - Access control notes

[Brian Stansberry]

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.
--------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-dev-forums/attachments/20130418/71d3590f/attachment.html