[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