[jboss-as7-dev] Securing the Console

[Jason T. Greene]

On 1/26/11 8:44 AM, Darran Lofthouse wrote:
> On 01/26/2011 02:38 PM, Brian Stansberry wrote:
>> On 1/25/11 9:00 AM, Darran Lofthouse wrote:
>>> Yes I agree it should all be role based.
>>>
>>> What I was really getting at here rather than the specifics of 'read
>>> only' or 'read write' attributes is that the detyped model is self
>>> describing - should that description actually take into account what the
>>> current user can actually do? i.e. The users view of the domain could
>>> filter out everything they don't have access to so they would only see a
>>> subset. Or would it still make sense to expose everything that they can
>>> not do and maybe provide an alternative indicator that although an
>>> operation exists they can not invoke it?
>>>
>>
>> Either of could be done by making security information available to
>> OperationHandler(s) that handle requests for descriptions. This would be
>> done by adding something to the NewOperationContext param. So, either or
>> both can be done without perturbing things much.
>>
>> TBH, I don't have a strong opinion on whether or not filtering out
>> descriptions is the right thing from the end user point of view.
>
> My strongest opinion here is that if the domain model can indicate what
> the current user can do then we should do that to avoid a situation
> where we have an authorization check within the core API and have the
> same logic duplicated in each console.

Agreed. We need to have consistency with the CLI and other admin 
interfaces anyway, so the core API is the most logical place to 
implement the security policy whatever it may be (filtering or not).

>
> Regarding the hiding I don't have a strong view either but maybe the
> core API should return the unfiltered view and then the console can
> decide if this should be filtered.  I think arguments one way or the
> other would be more likely in the context of the end user experience of
> the different consoles.

We really can go either way on this. It kind of depends on whether the 
description itself is actually a security leak. In many cases it is not, 
since the model is primarily JBoss open source code. There could be ISV 
or user extensions though, and maybe they want to "hide" stuff.

That said, I think filtering things you don't have access to is really 
more of a usability improvement than a security feature. Users that have 
a subset of permissions tend to only care about (or possibility 
understand) those things, so removing clutter helps them out.

Unless someone can come up with a compelling argument either way, then 
IMO the winner should be whatever is the easiest to implement.

-- 
Jason T. Greene
JBoss, a division of Red Hat