[jboss-as7-dev] Securing the Console

[Darran Lofthouse]

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.

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.

>>
>>
>> On 01/25/2011 02:25 PM, Heiko Braun wrote:
>>>
>>> On Jan 25, 2011, at 12:35 PM, Darran Lofthouse wrote:
>>>
>>>> Another aspect to consider is that values in the model can be
>>>> described as "read only" and "read write"
>>>
>>>
>>> IMO this distinction doesn't make sense at all. All attributes are
>>> read-only by default and for operations you don't know
>>> if they change state (guess this would be called 'write'). IMO we
>>> should drop these weak classifications and simply use a role based
>>> approach. Similar to the EE specs. Either can execute the operation or
>>> you can't, depending wether or nor you inherit a particular role.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>