[wildfly-dev] Pattern defined RBAC scoped roles

[Anil Saldanha]

The challenge with pattern based matching is that you provide access when you should not. Explicit definition of the grants is recommended.

So I support your thinking, Brian.

> On Apr 25, 2016, at 7:55 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> Perhaps. I'm a bit bit reluctant to move away from something powerful 
> and standard to something custom. Mostly because it's hard to move the 
> other way in the future while remaining compatible. But your point is 
> well taken.
> 
> How would you propose discriminating these cases?
> 
> 1) /subsystem=messaging is not allowed but its children are.
> 
> 2) /subsystem=messaging and its children are.
> 
> We also need to think about ObjectName patterns, which are not 
> inherently hierarchical.
> 
>> On 4/23/16 1:38 AM, Ladislav Thon wrote:
>> I only have a single comment: writing a regular expression can sometimes
>> be a bit tricky. Just see the example you used:
>> 
>>> (/profile=[^/]+)??/subsystem=logging(/.*)*
>> 
>> It's also fairly easy to write a regular expression that doesn't quite
>> do what you want it to do, in some corner cases. Finally, some
>> well-crafted regular expressions have running time in years or more (at
>> least in the java.util.regex implementation).
>> 
>> This all leads me to believe that maybe regular expressions are not the
>> best choice.
>> 
>> Instead, I'm thinking about address prefixes. So the role would be
>> specified by a set of valid addresses (including the "*" wildcard), and
>> only the specified resources and all their children would be accessible.
>> 
>> I'm specifically not thinking about _textual_ prefix, so e.g. prefix of
>> /subsystem=messaging would give you access to the old messaging
>> subsystem, but it _wouldn't_ give you access to the new
>> /subsystem=messaging-activemq, even if /subsystem=messaging is a textual
>> prefix.
>> 
>> Granted, that's way less powerful than regular expressions, but also
>> easier and safer to use.
>> 
>> WDYT? Am I being too paranoid here?
>> 
>> LT
>> _______________________________________________
>> 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
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev