[jboss-as7-dev] Securing the Console

[Brian Stansberry]

TBH, I've been thinking parochially in terms of securing the core 
management infrastructure on the DC/HC/standalone server and not 
specifically how that relates to the console UI. My bad, considering 
$subject.  The core management infrastructure could eventually support a 
pretty fine-grained ACL scheme; accept or reject each individual 
operation based on complex rules. But being that fine-grained may never 
work for the console, which will probably be much more task oriented and 
may want to hide a bunch of discrete operations behind a wizard or 
something.  And supporting stuff in the core that we can't represent in 
the UI is poor.

On 1/24/11 8:08 AM, Heiko Braun wrote:
>
> If I understand you correctly, you say:
>
> - we could do role based authentication

Right.

> - simplify it by providing fixed set of roles the UI knows of

For now, yes. But we'd want to understand how to make that set of roles 
configurable in the future.

> - allow for a highlevel mapping of roles to management use cases (what ever highlevel means)

This is the hard part. We'd want to design this to be flexible for the 
future. I suspect that's *much* easier to do for the core management 
infrastructure than it is for the console.

> - defer the decision how roles are being mapped to principals
>

Well, we'd have to solve this problem even for the simplest use case; 
i.e. just because a user can authenticate against corporate LDAP, he may 
not be an admin.

> is that correct?
>
> IMO and implementation that allows for this, is not too much work.
> But it would certainly prevent us from the pain of retro fitting it later on.
>

We need to hear from Anil and company, and I'm sure Darran is thinking 
hard about this as well.

Bottom line though, my initial feeling on this hasn't changed. Unless we 
can design something that will be extensible enough to meet long term 
needs, for AS 7.0 we're better off keeping it simple and sticking to a 
single role.

>
>
> On Jan 24, 2011, at 2:50 PM, Brian Stansberry wrote:
>
>> 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
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat