[jboss-as7-dev] Securing the Console

[Brian Stansberry]

On 1/21/11 11:04 AM, Heiko W.Rupp wrote:
>
> Am 21.01.2011 um 16:20 schrieb Brian Stansberry:
>> To me, "simple permissions" means if you can authenticate as an admin,
>> you're root. Everything else below is "complex permissions."
>
> One may (as we discussed on the phone iirc) have three categories:
> - root
> - deploy + view
> - view only
>

This is a kind of in-between stage between really simple permissions and 
truly complex permissions. In a "complex permission" system, we'd:

a) Figure out all the request characteristics which users would want to 
use in access control decisions.

b) Determine the control point(s) where the request could be evaluated.

c) Provide a configuration mechanism where users can express what roles 
are allowed to access what combination of characteristics. Expose such 
via the configuration files and all our management interfaces.

This 3 category approach eliminates c) by making it static. Big savings 
in effort. One that by itself doesn't prevent a full, more complex 
approach in a later release; i.e. we could always add configuration 
capability as a new feature.

It also affects a) by specifying a limited number of relevant request 
charactistics (is request read-only, is it deployment related.) That 
could be ok too as a way to reduce the amount of AS 7.0 work, but we'd 
need to think through what all the characteristics are that we're going 
to be asked (i.e. required) to support in the future. And make sure we 
don't design things in a way where that's not doable.

> If the REST verbs would be used, GET could be filtered for read-only,
> and all allowed for root - and the deploy role would need some
> filtering on the url.
>

The REST verbs are just other ways of describing CRUD. And what a 
request does in CRUD terms is certainly a big characteristic in any ACL 
system.

> But then urls could also be constructed in a way of
>
> /metric/domain/x/subsystem/y/...

Metrics aren't the only CRUD "Read" so I don't think elevating them to a 
top level concern in the model solves much.

> /deploy/server-group/x/..

Deployment related stuff is already in just a couple easily identified 
branches of the resource tree, so I don't think making it a top level 
concept helps much in terms of evaluating requests.

> /<other>/....
>
> Which can be relatively easy be matched to the above three roles.
>
> But then I am fine with "root" - only being present

:-)

It's a good discussion though.

-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat