[jboss-as7-dev] Securing the Console

[Darran Lofthouse]

On 01/21/2011 04:19 PM, Brian Stansberry wrote:
> Yeah, I figured that's where you were going, and it's fine in terms of
> direction; I didn't mean to be critical. I just want us to avoid REST
> analogies and focus on developing precise language for discussing stuff
> in terms of the core management API.

I will go through these classes and see how ACLs could be defined.  One 
of the benefits of having an admin console is that an administrator 
doesn't need to know the internals of domain management so we don't want 
to introduce that requirement when they secure it ;-)

> As you carry on with your thinking, be sure to get an understanding of
> how the classes in [1] work. See how well they fit/don't fit. Those,
> plus a convention of using "add" and "remove" as the name of operations
> that add/remove resources, should cover a very high % of the operations
> people will perform. The one that's somewhat neither fish nor fowl is
> reading a metric.

Yes during the discussion earlier in the week the metric being obtained 
by using an operation was also starting to raise questions ;-)

> We could model a metric as a read-only attribute and
> use the "read-attribute" operation, or we could have a bunch of ad-hoc
> "read-connection-count" operations, but neither feel exactly right. The
> former is closer.
>
> [1]
> https://github.com/bstansberry/jboss-as/tree/detyped2/controller/src/main/java/org/jboss/as/controller/operations/global
>
>
>> As it stands at the moment the HTTP API will probably not need to do a
>> lot more than the HTTP specific steps in the authentication process.
>>
>>>> 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.
>>
>> One issue you would have with dynamically identifying the profiles a
>> user can modify based on the server groups that they can administer is
>> that there would be nothing preventing them from updating their own
>> server group to use a different profile and hence gain access to a
>> profile they didn't previously have access to.
>>
>> You could then go to the level of defining permissions to specify which
>> profiles an administrator can actually use but by that point you may as
>> well be setting the permissions in relation to what they can actually
>> modify.
>>
>> Another way to view this may be to consider the profile as a template
>> for the server with either server group or host specific overrides, you
>> may have a limited set of users that can update the main templates and
>> then define administrators that can maintain their own profile to
>> aggregate the template profiles together into their own profile and then
>> apply server group / host overrides. Dynamically discovering which
>> utilised profiles can be modified would prevent the ability to do this.
>>
>> Also encouraging server group / host overrides over profile manipulation
>> could possibly be a best practice anyway to prevent administrators
>> inadvertently affecting all server groups in a domain when they only
>> really want to update one.
>>
>>
>>> 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.
>>>
>
>