[jboss-as7-dev] Securing the Console

Anil Saldhana Anil.Saldhana at redhat.com
Wed Jan 26 09:50:52 EST 2011


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.



More information about the jboss-as7-dev mailing list