[jboss-as7-dev] Securing the Console

[Heiko Braun]

If I understand you correctly, you say:

- we could do role based authentication
- simplify it by providing fixed set of roles the UI knows of
- allow for a highlevel mapping of roles to management use cases (what ever highlevel means)
- defer the decision how roles are being mapped to principals

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.



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