[jboss-as7-dev] Securing the Console

[Brian Stansberry]

On 1/21/11 9:50 AM, Darran Lofthouse wrote:
> 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
>

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.

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


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat