[jboss-as7-dev] Securing the Console

[Darran Lofthouse]

On 01/21/2011 03:20 PM, Brian Stansberry wrote:
> 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.

Yes the actual thinking regarding where to apply the security is always 
closer to the core management API - the thinking here was just that if 
it can cleanly map to four methods and a URI then we could look at a 
mapping similar to this for the core APIs

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