[wildfly-dev] Pattern defined RBAC scoped roles

[Brian Stansberry]

Gotcha; thanks.

I think there are two basic (non-regex) patterns that are likely to be 
useful:

1) Cross-profile perms

/profile=*/subsystem=logging

vs

/profile=default/subsystem=logging
/profile=ha/subsystem=logging
...
/profile=prof-52/subsystem=logging

2) Granting perms for an address and its children/

/subsystem=logging/**

Clean handling of 2) is a must. I'm sure we'd get complaints if we 
didn't support 1).

But full regex support isn't needed for those two.

On 4/25/16 10:07 AM, Anil Saldanha wrote:
> Hi Brian - I was just making a generic statement about staying away from
> pattern matching in ACLs given it is hard to debug and the possibility
> of Allow instead of Deny in unintended cases. Having explicit grants
> will make it cleaner.
>
> On Mon, Apr 25, 2016 at 9:28 AM, Brian Stansberry
> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> wrote:
>
>     On 4/25/16 8:09 AM, Anil Saldanha wrote:
>
>         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.
>
>
>     Did you mean you support Ladislav's thinking? His proposed approach
>     is more explicit.
>
>
>             On Apr 25, 2016, at 7:55 AM, Brian Stansberry
>             <brian.stansberry at redhat.com
>             <mailto: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
>                 <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>             https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>     --
>     Brian Stansberry
>     Senior Principal Software Engineer
>     JBoss by Red Hat
>
>


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