Pattern defined RBAC scoped roles

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Pattern defined RBAC scoped roles

Brian Stansberry
Yesterday afternoon I decided to scratch an itch I've had for a year. My
scratching seems to work so I'm tossing the idea out to get feedback on
whether it's wanted.

Idea is to let users create scoped roles for WildFly's management RBAC
feature that are based on address pattern matching. For example this
role would create a role where a user has non-sensitive write
permissions to resources in the logging subsystem, either on a DC or a
server:

<access-control provider="rbac">
   <pattern-scoped-roles>
     <role name="logmaint" base-role="Maintainer">
       <pattern
regular-expression="(/profile=[^/]+)??/subsystem=logging(/.*)*"/>
     </role>
    </pattern-scoped-roles>
             ....
</access-control>

A role like this could be used when the server config is really meant to
be locked down after boot, but you want to allow logging tweaks to get
diagnostic data if necessary.

A scoped role in our RBAC impl is one where the user gets the
permissions of some other role if the target resource is considered "in
scope", while if it's not they get lesser permissions (just
non-sensitive read perms, or for some cases no perms at all.)

What we have now are server group scoped roles and host scoped roles,
where what's "in scope" is calculated based on a configurable list of
server groups or hosts. This new type of scoped role instead does
pattern matching of the target address against a configurable list of
regular expressions. If there is no match the user gets non-sensitive
read perms.

There can be more than one pattern; a match against any means the
scoping constraint is satisfied.

The address matching is against the CLI-style representation of the
target resource address. When authorizing JMX operations the match is
against the canonical form of the ObjectName. JMX ops against the mbeans
in the jboss.as[.expr] domains match against the CLI-style address of
the management resource underlying the facade mbeans.

I have this working, see [1]. Needs tests but it works with manual testing.

[1] https://github.com/wildfly/wildfly-core/pull/1516

--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pattern defined RBAC scoped roles

Ladislav Thon
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pattern defined RBAC scoped roles

Brian Stansberry
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pattern defined RBAC scoped roles

Ladislav Thon
In reply to this post by Brian Stansberry
> 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.

I'll be the first to admit that a regexp-based scheme is inherently very
flexible, no doubt about that. (But with great power ...)

LT
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pattern defined RBAC scoped roles

kkhan

> On 25 Apr 2016, at 14:26, Ladislav Thon <[hidden email]> 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.
>
> 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?
>
> LT
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pattern defined RBAC scoped roles

Brian Stansberry
In reply to this post by Anil Saldanha
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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pattern defined RBAC scoped roles

Brian Stansberry
In reply to this post by kkhan
On 4/25/16 8:38 AM, Kabir Khan wrote:

>
>> On 25 Apr 2016, at 14:26, Ladislav Thon <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pattern defined RBAC scoped roles

Anil Saldanha
In reply to this post by Brian Stansberry
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


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


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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
> <[hidden email] <mailto:[hidden email]>> 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
>             <[hidden email]
>             <mailto:[hidden email]>> 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
>                 [hidden email]
>                 <mailto:[hidden email]>
>                 https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>             --
>             Brian Stansberry
>             Senior Principal Software Engineer
>             JBoss by Red Hat
>             _______________________________________________
>             wildfly-dev mailing list
>             [hidden email] <mailto:[hidden email]>
>             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
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pattern defined RBAC scoped roles

Ladislav Thon
> 1) Cross-profile perms
>
> /profile=*/subsystem=logging

Exactly, this is a syntax we already have.

> 2) Granting perms for an address and its children/
>
> /subsystem=logging/**
>
> Clean handling of 2) is a must.

Based on your previous question, this could actually mean 3 different
things:

a) only the resource and not its children
b) the resource and its children
c) only the resource's children, not the resource itself

I think /subsystem=logging could be used for a) or b). For c), I was
briefly thinking about /subsystem=logging/*=*, but I thought that we
surely don't support that, so I didn't bother trying and directly went
to the 'children-only' attribute. I tried it now and indeed we don't
support .../*=* :-)

But if we had to support all of a), b) and c), a multi-valued attribute
like children=yes|no|only (or recursive=yes|no|children-only, I didn't
give it much thought) could work.

LT
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev