[wildfly-dev] Pattern defined RBAC scoped roles

Brian Stansberry brian.stansberry at redhat.com
Mon Apr 25 10:37:26 EDT 2016


On 4/25/16 8:38 AM, Kabir Khan wrote:
>
>> On 25 Apr 2016, at 14:26, Ladislav Thon <lthon at redhat.com> wrote:
>>
>>> How would you propose discriminating these cases?
>>>
>>> 1) /subsystem=messaging is not allowed but its children are.
>>>
>>> 2) /subsystem=messaging and its children are.
>>
>> Well, there's not a lot of possibilities with a rigid scheme I'm
>> proposing. A boolean attribute 'children-only' is the only thing I can
>> come up with.
>>

Darn! I was hoping for an easy answer and asked because I didn't have 
time at the moment to think. I'm still hoping. ;)

TBH, 'children-only' isn't so terrible if there isn't some standard 
syntax for this kind of thing.

>> I'll be the first to admit that a regexp-based scheme is inherently very
>> flexible, no doubt about that. (But with great power ...)
> To help with this, could we not add an operation which shows which resources will be granted access?

I'm not sure how that could work if the base-role is Operator, which 
only has rights to runtime-only changes. For base roles with perms to 
write the config we could recursively test 
OperationContext.readResourceForUpdate() but that wouldn't show any 
perms at all for Operator.

>>
>> LT
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat


More information about the wildfly-dev mailing list