9:20 a.m.
On 1/21/11 5:03 AM, Darran Lofthouse wrote:
Yes I would not be surprised if the requirement comes in - the
filter
that is available for the JMX console in the AS/EAP 4/5 distributions is
used with occasional requests on how to refine it further.
Oh, for sure it will come in. :-)
One point regarding the requirements is that it is 'complex
permissions'
that are delegated to JON so there is still the middle ground of 'simple
permissions' not explicitly included or excluded.
To me, "simple permissions" means if you can authenticate as an admin,
you're root. Everything else below is "complex permissions."
At the very least tackling simple permissions could provide the same
kind of functionality as is provided by the filter for the JMX console
and this would ensure the domain management does contain some form of
authorization that can potentially be extended in the future to
introduce more complex permissions.
I know the API discussion has moved on but in terms of a REST API with
everything mapped to a URI with one of four methods
(GET/POST/PUT/DELETE) you could fairly simply define ACLs as a
combination of methods and URIs that are either allowed or prohibited
for a role or set of roles. Making use of wildcards and using the
allowed and prohibited for the URIs similar to Ant includes and excludes
you could have a lot of flexibility without the ACL mechanism itself
being overly complex.
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.
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.
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.
If there is a requirement to have administrators that look after a
server group and the profiles that feed into the server group suitable
naming conventions could then be defined at the time the domains are
defined to allow a separation in configuration rather than trying to
implement identification of permissions by traversing the hierarchy from
server group and up.
Yes, that provides a workaround for organizations who
Regards,
Darran Lofthouse.
On 01/20/2011 08:05 PM, Brian Stansberry wrote:
> 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