[jboss-as7-dev] Securing the Console

[Darran Lofthouse]

Yes I would not be surprised if the requirement comes in - the filter 
that is available for the JMX console in the AS/EAP 4/5 distributions is 
used with occasional requests on how to refine it further.

One point regarding the requirements is that it is 'complex permissions' 
that are delegated to JON so there is still the middle ground of 'simple 
permissions' not explicitly included or excluded.

At the very least tackling simple permissions could provide the same 
kind of functionality as is provided by the filter for the JMX console 
and this would ensure the domain management does contain some form of 
authorization that can potentially be extended in the future to 
introduce more complex permissions.

I know the API discussion has moved on but in terms of a REST API with 
everything mapped to a URI with one of four methods 
(GET/POST/PUT/DELETE) you could fairly simply define ACLs as a 
combination of methods and URIs that are either allowed or prohibited 
for a role or set of roles.  Making use of wildcards and using the 
allowed and prohibited for the URIs similar to Ant includes and excludes 
you could have a lot of flexibility without the ACL mechanism itself 
being overly complex.

For the server group administration would we really want to make it as 
complex as dynamically identifying which profiles are pulled into which 
server groups?

During the meeting it was identified that we need further clarification 
regarding how either server group or host specific configuration and 
updates would be provided so that links closely with this but to 
simplify both the implementation and the description / documentation of 
the ACLs wouldn't it make sense to just work on the lines of groups of 
users being given access to maintain specific profiles and other groups 
of users to be given access to maintain specific server groups.

If there is a requirement to have administrators that look after a 
server group and the profiles that feed into the server group suitable 
naming conventions could then be defined at the time the domains are 
defined to allow a separation in configuration rather than trying to 
implement identification of permissions by traversing the hierarchy from 
server group and up.

Regards,
Darran Lofthouse.


On 01/20/2011 08:05 PM, Brian Stansberry wrote:
> On 1/20/11 12:56 PM, Jason T. Greene wrote:
>> On 1/20/11 11:00 AM, Heiko Braun wrote:
>
> <snip/>
>
>>
>> - The ERD clarified that ACLS would be a JON feature above the console.
>> We could if we have time, support some form of basic permissions
>>
>
> I think we should think a bit about how ACLs could work and confirm that
> our design could support them. There's no requirement to implement them,
> but I'd be surprised if there wasn't such a requirement in a year or so,
> so good to think a bit.
>
> Our model has:
>
> -- hierarchical addresses
> -- attribute names
> -- operation names
> -- some generic metadata that we can attach to operation descriptions,
> e.g. RO/WO/RW, affects config, affects runtime state
>
> It seems like out of that some reasonable ACL schemes could be derived.
> It would be good to think a bit about how the enforcement would work and
> whether the necessary information is cheaply available at the control
> point. (E.g. that "RO/WO/RW, affects config, affects runtime state"
> metadata isn't super-cheaply available.)
>
> What I see that's not so clean for ACLs is the way server groups work.
> Server groups have shared resources (e.g. profile configs, host
> interface configs) mapped on to them, and then servers as logical
> children. That mapping is problematic, e.g. if only users in the
> "groupA-admin" role could touch stuff that affects server group "groupA"
> (a likely construct), then before updating anything we'd have to see if
> that something directly or indirectly affects groupA.
>