[jboss-as7-dev] Securing the Console

Brian Stansberry brian.stansberry at redhat.com
Thu Jan 20 15:05:55 EST 2011


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



More information about the jboss-as7-dev mailing list