[jboss-as7-dev] Securing the Console

[Darran Lofthouse]

What would we think of a plug-in within the console simplifying the 
manipulation of permissions?

Here I am trying to think along the lines that the permissions should be 
modifiable using all admin interfaces so Console, HTTP, CLI and Remoting 
(Is that the correct way to refer to direct Java access?) - an admin 
console plug-in would be specific for console users only.

Regards,
Darran Lofthouse.




On 01/26/2011 02:50 PM, Anil Saldhana wrote:
> Hi Darran,
> I am presuming that there will be some console plugin to manage the fine
> grained authorization aspects of the console. I proposed xacml as it is
> a decent standard for FGA and better than coming up with some ad-hoc ACL
> based solutions.
>
> Regards,
> Anil
>
> On 01/26/2011 04:55 AM, Darran Lofthouse wrote:
>> Hi Anil,
>>
>> I have read through the XACML specification and it does seem very
>> suited as the mechanism to define the policies.
>>
>> There is one thing that concerns me however and that is the complexity
>> of the configuration for administrators that are new to XACML and also
>> don't necessarily want to know the inner workings of domain
>> management. I also see some similar concerns in one of your previous
>> blog posts: -
>>
>> http://anil-identity.blogspot.com/search/label/XACML
>>
>> To overcome this would it then make sense for us to define a schema
>> for a simplified policy that users can use and manipulate through the
>> domain model - this could then undergo a transformation into a XACML
>> policy.
>>
>> This would then potentially give us the benefit of providing a
>> simplified authorization / ACL configuration for users from the
>> beginning and then for advanced users they could switch directly to
>> XACML and write their own policies. At our own pace we can then expand
>> on our schema but for the users that want more than we provide they
>> will always have the option to switch to an advanced mode.
>>
>> (For switching to an advanced mode I would think you are definitely
>> outside the scope of any tooling we provide assisting with the XACML
>> version of the configuration which is why it would still be beneficial
>> to expand on our schema)
>>
>> Another aspect I am also still looking into is how much we want to
>> know about what a user can do before they do it or if we are just
>> interested in an authorization check at the time they attempt an
>> action so I need to consider how this would work with XACML policies.
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>>
>> On 01/25/2011 03:58 PM, Anil Saldhana wrote:
>>> Darran,
>>> take a look at xacml policies. It gives the externalization of
>>> policies plus the fine grained aspects perfectly
>>> suited for management console.
>>>
>>> Regards,
>>> Anil
>>>
>>> On 01/25/2011 05:35 AM, Darran Lofthouse wrote:
>>>> On 01/25/2011 08:41 AM, Heiko Braun wrote:
>>>>> a) One for the client server communication (which operation can a
>>>>> 'role' invoke?)
>>>>> b) another one discriminating which parts of the UI the user
>>>>> actually gets to see.
>>>> We do need to be careful that the console itself doesn't attempt to
>>>> perform it's own restrictions with it's own authorization checking as
>>>> this can become quite easy for administrators to become dependent on
>>>> and
>>>> not realise that their users can bypass this and call the APIs
>>>> directly.
>>>>
>>>> Also based on past experience I think we want to be able to document
>>>> the
>>>> security once and for it to then apply equally to all management APIs.
>>>>
>>>> From the perspective of the console I think this should be considered
>>>> more from the point of preventing users wasting their time performing
>>>> operations in the console that will subsequently fail when applied.
>>>>
>>>> I am going to go through the example Brian has now committed to take a
>>>> better look at these potential calls but I am wondering if it would
>>>> make
>>>> sense to have some form of "What can I do here?" or "What operations am
>>>> I allowed to call?" calls for the console to be able to discover this?
>>>>
>>>> Another aspect to consider is that values in the model can be described
>>>> as "read only" and "read write" - would it make sense for this to also
>>>> reflect what the user can actually do or maybe even add a "read write -
>>>> but not for you".
>>>>
>>>> Regards,
>>>> Darran Lofthouse.