[jboss-as7-dev] Securing the Console

[Brian Stansberry]

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.

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


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat