[jboss-as7-dev] Securing the Console

[Brian Stansberry]

On 1/21/11 5:03 AM, Darran Lofthouse wrote:
> 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.
>

Oh, for sure it will come in. :-)

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

To me, "simple permissions" means if you can authenticate as an admin, 
you're root. Everything else below is "complex permissions."

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

Think in terms of the core detyped management API, not REST. Your line 
of thinking is fine, but try not to discuss things in terms of REST. 
HTTP is just one mechanism for exposing the core management API.

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

Would that be acceptable to users? Honestly asking; I don't know.

90% of what it means to *configure* a server group is:

1) Configure the profile it runs.
2) Map deployments to the group.

So, 1) is the issue. But managing configuration is just one part of what 
it means to manage something. If excluding 1) from the rights of users 
in the "server-groupA-admin" role, is acceptable, that certainly 
simplifies things.

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

Yes, that provides a workaround for organizations who
> 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.
>>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat