[jboss-as7-dev] Securing the Console

[Darran Lofthouse]

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.
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev