You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Claude Warren <cl...@xenei.com> on 2024/09/03 11:21:46 UTC
Possible bug in Authorize by ResourceTypeQue
*Setup:*
Superuser = "User:superman"
ACLs added to system
new StandardAcl(TOPIC, "foo", PREFIXED, "User:alice", WILDCARD, READ, DENY)
new StandardAcl(TOPIC, "foobar", LITERAL, "User:alice", WILDCARD, READ,
ALLOW)
new StandardAcl(TOPIC, "foo", PREFIXED, "User:bob", WILDCARD, READ, ALLOW)
ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true"
AuthorizerContext requestContext = MockAuthorizableRequestContext with
principal = User:alice
host = InetAddress.getLocalHost()
*Method Call:*
authorizer.authorizeByResourceType(requestContext, READ, TOPIC)
*Question:*
Should the result be true because there is a LITERAL READ ALLOW on "foobar"
or should the result be false because there is an overriding PREFIXED READ
DENY on "foo" ?
--
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: Possible bug in Authorize by ResourceTypeQue
Posted by Rajini Sivaram <ra...@gmail.com>.
I think we don't take implied access into account for
authorizeByResourceType. The implied access is the other way round: ALLOW
READ implies ALLOW DESCRIBE. So in your example, it doesn't make any
difference to the result of authorizeByResourceType for READ whether
implied access is taken into account or not. We only grant implied access
for DESCRIBE and DESCRIBE_CONFIGS. While authorizeByResourceType is only
used with WRITE that is never implied. If we were to use
authorizeByResourceType for DESCRIBE or DESCRIBE_CONFIGS in the future, we
probably would want to take implied access into account.
ALL explicitly grants access to all operations, so that is taken into
account for authorizeByResourceType.
On Wed, Sep 4, 2024 at 8:12 AM Claude Warren, Jr
<cl...@aiven.io.invalid> wrote:
> Thank you for your detailed answer.
>
> One further clarification: There is an "Implies" calculation around the
> "ALLOW" AclOperation (e.g. ALLOW DESCRIBE implies READ, WRITE, DELETE,
> ALTER). Is this also considered when determining the ability to READ?
> (e.g. if alice has an DESCRIBE TOPIC ALLOW Acl does the query for Alice
> READ TOPIC return true?)
>
> Thanks again,
> Claude
>
> On Tue, Sep 3, 2024 at 7:21 PM Rajini Sivaram <ra...@gmail.com>
> wrote:
>
> > > If ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true" then
> > > authorizeByResourceType should return true in all cases since the user
> > > would have access for any operation on any undefined topic?
> >
> >
> > It should return false if the user is denied all access using wildcard
> ACL.
> > For example if you add an ACL to DENY the operation READ for LITERAL
> > *, authorizeByResourceType for READ fails. Otherwise, access is granted.
> >
> > Followup2: your answer speaks directly to "WRITE" access. My example was
> > > READ access. So the question method is answering then is: Does the
> user
> > > have access to READ any TOPIC?
> >
> >
> > Yes, that is the question the method is answering. Sorry, I answered
> using
> > WRITE because we currently use `authorizeByResourceType` only for
> `WRITE`.
> > But the same logic applies for any operation from the authorizer point of
> > view. So in your example, READ is authorized because alice is allowed to
> > read a topic that doesn't start with `foo`.
> >
> > And that is further restricted by the requestContext host is it not?
> >
> > Yes, it is restricted by host. So the question the method is answering
> is:
> > Does the user have access to READ any TOPIC from the host in the request
> > context?
> >
> >
> > On Tue, Sep 3, 2024 at 2:16 PM Claude Warren, Jr
> > <cl...@aiven.io.invalid> wrote:
> >
> > > Followup2: your answer speaks directly to "WRITE" access. My example
> was
> > > READ access. So the question method is answering then is: Does the
> user
> > > have access to READ any TOPIC? And that is further restricted by the
> > > requestContext host is it not?
> > >
> > >
> > > On Tue, Sep 3, 2024 at 2:10 PM Claude Warren, Jr <
> claude.warren@aiven.io
> > >
> > > wrote:
> > >
> > > > Followup: If ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true" then
> > > > authorizeByResourceType should return true in all cases since the
> user
> > > > would have access for any operation on any undefined topic?
> > > >
> > > >
> > > > On Tue, Sep 3, 2024 at 2:08 PM Claude Warren, Jr <
> > claude.warren@aiven.io
> > > >
> > > > wrote:
> > > >
> > > >> I am working on a replacement for the StandardAuthorizer and my
> > > >> implementation DENIED while the standard implementation ALLOWED. In
> > > >> reading the specs I thought it should be DENIED. But your statement
> > > makes
> > > >> it clear that I misread.
> > > >>
> > > >> Thank you,
> > > >> Claude
> > > >>
> > > >> On Tue, Sep 3, 2024 at 1:14 PM Rajini Sivaram <
> > rajinisivaram@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> Hi Claude,
> > > >>>
> > > >>> `authorizeByResourceType` doesn't grant access to any specific
> topic,
> > > it
> > > >>> grants access to idempotent write if the user has access to write
> to
> > > any
> > > >>> topic (which may or may not exist). In this case,
> > > >>> ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true", so `User:alice`
> > can
> > > >>> write to a topic that doesn't start with `foo` and hence
> > > >>> `authorizeByResourceType` should be ALLOWED. What was the behaviour
> > you
> > > >>> observed?
> > > >>>
> > > >>> Regards,
> > > >>>
> > > >>> Rajini
> > > >>>
> > > >>>
> > > >>> On Tue, Sep 3, 2024 at 12:22 PM Claude Warren <cl...@xenei.com>
> > > wrote:
> > > >>>
> > > >>> > *Setup:*
> > > >>> > Superuser = "User:superman"
> > > >>> >
> > > >>> > ACLs added to system
> > > >>> > new StandardAcl(TOPIC, "foo", PREFIXED, "User:alice", WILDCARD,
> > READ,
> > > >>> DENY)
> > > >>> > new StandardAcl(TOPIC, "foobar", LITERAL, "User:alice", WILDCARD,
> > > READ,
> > > >>> > ALLOW)
> > > >>> > new StandardAcl(TOPIC, "foo", PREFIXED, "User:bob", WILDCARD,
> READ,
> > > >>> ALLOW)
> > > >>> >
> > > >>> > ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true"
> > > >>> >
> > > >>> > AuthorizerContext requestContext = MockAuthorizableRequestContext
> > > with
> > > >>> > principal = User:alice
> > > >>> > host = InetAddress.getLocalHost()
> > > >>> >
> > > >>> >
> > > >>> > *Method Call:*
> > > >>> >
> > > >>> > authorizer.authorizeByResourceType(requestContext, READ, TOPIC)
> > > >>> >
> > > >>> > *Question:*
> > > >>> >
> > > >>> > Should the result be true because there is a LITERAL READ ALLOW
> on
> > > >>> "foobar"
> > > >>> > or should the result be false because there is an overriding
> > PREFIXED
> > > >>> READ
> > > >>> > DENY on "foo" ?
> > > >>> >
> > > >>> >
> > > >>> >
> > > >>> > --
> > > >>> > LinkedIn: http://www.linkedin.com/in/claudewarren
> > > >>> >
> > > >>>
> > > >>
> > >
> >
>
Re: Possible bug in Authorize by ResourceTypeQue
Posted by "Claude Warren, Jr" <cl...@aiven.io.INVALID>.
Thank you for your detailed answer.
One further clarification: There is an "Implies" calculation around the
"ALLOW" AclOperation (e.g. ALLOW DESCRIBE implies READ, WRITE, DELETE,
ALTER). Is this also considered when determining the ability to READ?
(e.g. if alice has an DESCRIBE TOPIC ALLOW Acl does the query for Alice
READ TOPIC return true?)
Thanks again,
Claude
On Tue, Sep 3, 2024 at 7:21 PM Rajini Sivaram <ra...@gmail.com>
wrote:
> > If ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true" then
> > authorizeByResourceType should return true in all cases since the user
> > would have access for any operation on any undefined topic?
>
>
> It should return false if the user is denied all access using wildcard ACL.
> For example if you add an ACL to DENY the operation READ for LITERAL
> *, authorizeByResourceType for READ fails. Otherwise, access is granted.
>
> Followup2: your answer speaks directly to "WRITE" access. My example was
> > READ access. So the question method is answering then is: Does the user
> > have access to READ any TOPIC?
>
>
> Yes, that is the question the method is answering. Sorry, I answered using
> WRITE because we currently use `authorizeByResourceType` only for `WRITE`.
> But the same logic applies for any operation from the authorizer point of
> view. So in your example, READ is authorized because alice is allowed to
> read a topic that doesn't start with `foo`.
>
> And that is further restricted by the requestContext host is it not?
>
> Yes, it is restricted by host. So the question the method is answering is:
> Does the user have access to READ any TOPIC from the host in the request
> context?
>
>
> On Tue, Sep 3, 2024 at 2:16 PM Claude Warren, Jr
> <cl...@aiven.io.invalid> wrote:
>
> > Followup2: your answer speaks directly to "WRITE" access. My example was
> > READ access. So the question method is answering then is: Does the user
> > have access to READ any TOPIC? And that is further restricted by the
> > requestContext host is it not?
> >
> >
> > On Tue, Sep 3, 2024 at 2:10 PM Claude Warren, Jr <claude.warren@aiven.io
> >
> > wrote:
> >
> > > Followup: If ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true" then
> > > authorizeByResourceType should return true in all cases since the user
> > > would have access for any operation on any undefined topic?
> > >
> > >
> > > On Tue, Sep 3, 2024 at 2:08 PM Claude Warren, Jr <
> claude.warren@aiven.io
> > >
> > > wrote:
> > >
> > >> I am working on a replacement for the StandardAuthorizer and my
> > >> implementation DENIED while the standard implementation ALLOWED. In
> > >> reading the specs I thought it should be DENIED. But your statement
> > makes
> > >> it clear that I misread.
> > >>
> > >> Thank you,
> > >> Claude
> > >>
> > >> On Tue, Sep 3, 2024 at 1:14 PM Rajini Sivaram <
> rajinisivaram@gmail.com>
> > >> wrote:
> > >>
> > >>> Hi Claude,
> > >>>
> > >>> `authorizeByResourceType` doesn't grant access to any specific topic,
> > it
> > >>> grants access to idempotent write if the user has access to write to
> > any
> > >>> topic (which may or may not exist). In this case,
> > >>> ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true", so `User:alice`
> can
> > >>> write to a topic that doesn't start with `foo` and hence
> > >>> `authorizeByResourceType` should be ALLOWED. What was the behaviour
> you
> > >>> observed?
> > >>>
> > >>> Regards,
> > >>>
> > >>> Rajini
> > >>>
> > >>>
> > >>> On Tue, Sep 3, 2024 at 12:22 PM Claude Warren <cl...@xenei.com>
> > wrote:
> > >>>
> > >>> > *Setup:*
> > >>> > Superuser = "User:superman"
> > >>> >
> > >>> > ACLs added to system
> > >>> > new StandardAcl(TOPIC, "foo", PREFIXED, "User:alice", WILDCARD,
> READ,
> > >>> DENY)
> > >>> > new StandardAcl(TOPIC, "foobar", LITERAL, "User:alice", WILDCARD,
> > READ,
> > >>> > ALLOW)
> > >>> > new StandardAcl(TOPIC, "foo", PREFIXED, "User:bob", WILDCARD, READ,
> > >>> ALLOW)
> > >>> >
> > >>> > ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true"
> > >>> >
> > >>> > AuthorizerContext requestContext = MockAuthorizableRequestContext
> > with
> > >>> > principal = User:alice
> > >>> > host = InetAddress.getLocalHost()
> > >>> >
> > >>> >
> > >>> > *Method Call:*
> > >>> >
> > >>> > authorizer.authorizeByResourceType(requestContext, READ, TOPIC)
> > >>> >
> > >>> > *Question:*
> > >>> >
> > >>> > Should the result be true because there is a LITERAL READ ALLOW on
> > >>> "foobar"
> > >>> > or should the result be false because there is an overriding
> PREFIXED
> > >>> READ
> > >>> > DENY on "foo" ?
> > >>> >
> > >>> >
> > >>> >
> > >>> > --
> > >>> > LinkedIn: http://www.linkedin.com/in/claudewarren
> > >>> >
> > >>>
> > >>
> >
>
Re: Possible bug in Authorize by ResourceTypeQue
Posted by Rajini Sivaram <ra...@gmail.com>.
> If ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true" then
> authorizeByResourceType should return true in all cases since the user
> would have access for any operation on any undefined topic?
It should return false if the user is denied all access using wildcard ACL.
For example if you add an ACL to DENY the operation READ for LITERAL
*, authorizeByResourceType for READ fails. Otherwise, access is granted.
Followup2: your answer speaks directly to "WRITE" access. My example was
> READ access. So the question method is answering then is: Does the user
> have access to READ any TOPIC?
Yes, that is the question the method is answering. Sorry, I answered using
WRITE because we currently use `authorizeByResourceType` only for `WRITE`.
But the same logic applies for any operation from the authorizer point of
view. So in your example, READ is authorized because alice is allowed to
read a topic that doesn't start with `foo`.
And that is further restricted by the requestContext host is it not?
Yes, it is restricted by host. So the question the method is answering is:
Does the user have access to READ any TOPIC from the host in the request
context?
On Tue, Sep 3, 2024 at 2:16 PM Claude Warren, Jr
<cl...@aiven.io.invalid> wrote:
> Followup2: your answer speaks directly to "WRITE" access. My example was
> READ access. So the question method is answering then is: Does the user
> have access to READ any TOPIC? And that is further restricted by the
> requestContext host is it not?
>
>
> On Tue, Sep 3, 2024 at 2:10 PM Claude Warren, Jr <cl...@aiven.io>
> wrote:
>
> > Followup: If ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true" then
> > authorizeByResourceType should return true in all cases since the user
> > would have access for any operation on any undefined topic?
> >
> >
> > On Tue, Sep 3, 2024 at 2:08 PM Claude Warren, Jr <claude.warren@aiven.io
> >
> > wrote:
> >
> >> I am working on a replacement for the StandardAuthorizer and my
> >> implementation DENIED while the standard implementation ALLOWED. In
> >> reading the specs I thought it should be DENIED. But your statement
> makes
> >> it clear that I misread.
> >>
> >> Thank you,
> >> Claude
> >>
> >> On Tue, Sep 3, 2024 at 1:14 PM Rajini Sivaram <ra...@gmail.com>
> >> wrote:
> >>
> >>> Hi Claude,
> >>>
> >>> `authorizeByResourceType` doesn't grant access to any specific topic,
> it
> >>> grants access to idempotent write if the user has access to write to
> any
> >>> topic (which may or may not exist). In this case,
> >>> ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true", so `User:alice` can
> >>> write to a topic that doesn't start with `foo` and hence
> >>> `authorizeByResourceType` should be ALLOWED. What was the behaviour you
> >>> observed?
> >>>
> >>> Regards,
> >>>
> >>> Rajini
> >>>
> >>>
> >>> On Tue, Sep 3, 2024 at 12:22 PM Claude Warren <cl...@xenei.com>
> wrote:
> >>>
> >>> > *Setup:*
> >>> > Superuser = "User:superman"
> >>> >
> >>> > ACLs added to system
> >>> > new StandardAcl(TOPIC, "foo", PREFIXED, "User:alice", WILDCARD, READ,
> >>> DENY)
> >>> > new StandardAcl(TOPIC, "foobar", LITERAL, "User:alice", WILDCARD,
> READ,
> >>> > ALLOW)
> >>> > new StandardAcl(TOPIC, "foo", PREFIXED, "User:bob", WILDCARD, READ,
> >>> ALLOW)
> >>> >
> >>> > ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true"
> >>> >
> >>> > AuthorizerContext requestContext = MockAuthorizableRequestContext
> with
> >>> > principal = User:alice
> >>> > host = InetAddress.getLocalHost()
> >>> >
> >>> >
> >>> > *Method Call:*
> >>> >
> >>> > authorizer.authorizeByResourceType(requestContext, READ, TOPIC)
> >>> >
> >>> > *Question:*
> >>> >
> >>> > Should the result be true because there is a LITERAL READ ALLOW on
> >>> "foobar"
> >>> > or should the result be false because there is an overriding PREFIXED
> >>> READ
> >>> > DENY on "foo" ?
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > LinkedIn: http://www.linkedin.com/in/claudewarren
> >>> >
> >>>
> >>
>
Re: Possible bug in Authorize by ResourceTypeQue
Posted by "Claude Warren, Jr" <cl...@aiven.io.INVALID>.
Followup2: your answer speaks directly to "WRITE" access. My example was
READ access. So the question method is answering then is: Does the user
have access to READ any TOPIC? And that is further restricted by the
requestContext host is it not?
On Tue, Sep 3, 2024 at 2:10 PM Claude Warren, Jr <cl...@aiven.io>
wrote:
> Followup: If ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true" then
> authorizeByResourceType should return true in all cases since the user
> would have access for any operation on any undefined topic?
>
>
> On Tue, Sep 3, 2024 at 2:08 PM Claude Warren, Jr <cl...@aiven.io>
> wrote:
>
>> I am working on a replacement for the StandardAuthorizer and my
>> implementation DENIED while the standard implementation ALLOWED. In
>> reading the specs I thought it should be DENIED. But your statement makes
>> it clear that I misread.
>>
>> Thank you,
>> Claude
>>
>> On Tue, Sep 3, 2024 at 1:14 PM Rajini Sivaram <ra...@gmail.com>
>> wrote:
>>
>>> Hi Claude,
>>>
>>> `authorizeByResourceType` doesn't grant access to any specific topic, it
>>> grants access to idempotent write if the user has access to write to any
>>> topic (which may or may not exist). In this case,
>>> ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true", so `User:alice` can
>>> write to a topic that doesn't start with `foo` and hence
>>> `authorizeByResourceType` should be ALLOWED. What was the behaviour you
>>> observed?
>>>
>>> Regards,
>>>
>>> Rajini
>>>
>>>
>>> On Tue, Sep 3, 2024 at 12:22 PM Claude Warren <cl...@xenei.com> wrote:
>>>
>>> > *Setup:*
>>> > Superuser = "User:superman"
>>> >
>>> > ACLs added to system
>>> > new StandardAcl(TOPIC, "foo", PREFIXED, "User:alice", WILDCARD, READ,
>>> DENY)
>>> > new StandardAcl(TOPIC, "foobar", LITERAL, "User:alice", WILDCARD, READ,
>>> > ALLOW)
>>> > new StandardAcl(TOPIC, "foo", PREFIXED, "User:bob", WILDCARD, READ,
>>> ALLOW)
>>> >
>>> > ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true"
>>> >
>>> > AuthorizerContext requestContext = MockAuthorizableRequestContext with
>>> > principal = User:alice
>>> > host = InetAddress.getLocalHost()
>>> >
>>> >
>>> > *Method Call:*
>>> >
>>> > authorizer.authorizeByResourceType(requestContext, READ, TOPIC)
>>> >
>>> > *Question:*
>>> >
>>> > Should the result be true because there is a LITERAL READ ALLOW on
>>> "foobar"
>>> > or should the result be false because there is an overriding PREFIXED
>>> READ
>>> > DENY on "foo" ?
>>> >
>>> >
>>> >
>>> > --
>>> > LinkedIn: http://www.linkedin.com/in/claudewarren
>>> >
>>>
>>
Re: Possible bug in Authorize by ResourceTypeQue
Posted by "Claude Warren, Jr" <cl...@aiven.io.INVALID>.
Followup: If ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true" then
authorizeByResourceType should return true in all cases since the user
would have access for any operation on any undefined topic?
On Tue, Sep 3, 2024 at 2:08 PM Claude Warren, Jr <cl...@aiven.io>
wrote:
> I am working on a replacement for the StandardAuthorizer and my
> implementation DENIED while the standard implementation ALLOWED. In
> reading the specs I thought it should be DENIED. But your statement makes
> it clear that I misread.
>
> Thank you,
> Claude
>
> On Tue, Sep 3, 2024 at 1:14 PM Rajini Sivaram <ra...@gmail.com>
> wrote:
>
>> Hi Claude,
>>
>> `authorizeByResourceType` doesn't grant access to any specific topic, it
>> grants access to idempotent write if the user has access to write to any
>> topic (which may or may not exist). In this case,
>> ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true", so `User:alice` can
>> write to a topic that doesn't start with `foo` and hence
>> `authorizeByResourceType` should be ALLOWED. What was the behaviour you
>> observed?
>>
>> Regards,
>>
>> Rajini
>>
>>
>> On Tue, Sep 3, 2024 at 12:22 PM Claude Warren <cl...@xenei.com> wrote:
>>
>> > *Setup:*
>> > Superuser = "User:superman"
>> >
>> > ACLs added to system
>> > new StandardAcl(TOPIC, "foo", PREFIXED, "User:alice", WILDCARD, READ,
>> DENY)
>> > new StandardAcl(TOPIC, "foobar", LITERAL, "User:alice", WILDCARD, READ,
>> > ALLOW)
>> > new StandardAcl(TOPIC, "foo", PREFIXED, "User:bob", WILDCARD, READ,
>> ALLOW)
>> >
>> > ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true"
>> >
>> > AuthorizerContext requestContext = MockAuthorizableRequestContext with
>> > principal = User:alice
>> > host = InetAddress.getLocalHost()
>> >
>> >
>> > *Method Call:*
>> >
>> > authorizer.authorizeByResourceType(requestContext, READ, TOPIC)
>> >
>> > *Question:*
>> >
>> > Should the result be true because there is a LITERAL READ ALLOW on
>> "foobar"
>> > or should the result be false because there is an overriding PREFIXED
>> READ
>> > DENY on "foo" ?
>> >
>> >
>> >
>> > --
>> > LinkedIn: http://www.linkedin.com/in/claudewarren
>> >
>>
>
Re: Possible bug in Authorize by ResourceTypeQue
Posted by "Claude Warren, Jr" <cl...@aiven.io.INVALID>.
I am working on a replacement for the StandardAuthorizer and my
implementation DENIED while the standard implementation ALLOWED. In
reading the specs I thought it should be DENIED. But your statement makes
it clear that I misread.
Thank you,
Claude
On Tue, Sep 3, 2024 at 1:14 PM Rajini Sivaram <ra...@gmail.com>
wrote:
> Hi Claude,
>
> `authorizeByResourceType` doesn't grant access to any specific topic, it
> grants access to idempotent write if the user has access to write to any
> topic (which may or may not exist). In this case,
> ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true", so `User:alice` can
> write to a topic that doesn't start with `foo` and hence
> `authorizeByResourceType` should be ALLOWED. What was the behaviour you
> observed?
>
> Regards,
>
> Rajini
>
>
> On Tue, Sep 3, 2024 at 12:22 PM Claude Warren <cl...@xenei.com> wrote:
>
> > *Setup:*
> > Superuser = "User:superman"
> >
> > ACLs added to system
> > new StandardAcl(TOPIC, "foo", PREFIXED, "User:alice", WILDCARD, READ,
> DENY)
> > new StandardAcl(TOPIC, "foobar", LITERAL, "User:alice", WILDCARD, READ,
> > ALLOW)
> > new StandardAcl(TOPIC, "foo", PREFIXED, "User:bob", WILDCARD, READ,
> ALLOW)
> >
> > ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true"
> >
> > AuthorizerContext requestContext = MockAuthorizableRequestContext with
> > principal = User:alice
> > host = InetAddress.getLocalHost()
> >
> >
> > *Method Call:*
> >
> > authorizer.authorizeByResourceType(requestContext, READ, TOPIC)
> >
> > *Question:*
> >
> > Should the result be true because there is a LITERAL READ ALLOW on
> "foobar"
> > or should the result be false because there is an overriding PREFIXED
> READ
> > DENY on "foo" ?
> >
> >
> >
> > --
> > LinkedIn: http://www.linkedin.com/in/claudewarren
> >
>
Re: Possible bug in Authorize by ResourceTypeQue
Posted by Rajini Sivaram <ra...@gmail.com>.
Hi Claude,
`authorizeByResourceType` doesn't grant access to any specific topic, it
grants access to idempotent write if the user has access to write to any
topic (which may or may not exist). In this case,
ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true", so `User:alice` can
write to a topic that doesn't start with `foo` and hence
`authorizeByResourceType` should be ALLOWED. What was the behaviour you
observed?
Regards,
Rajini
On Tue, Sep 3, 2024 at 12:22 PM Claude Warren <cl...@xenei.com> wrote:
> *Setup:*
> Superuser = "User:superman"
>
> ACLs added to system
> new StandardAcl(TOPIC, "foo", PREFIXED, "User:alice", WILDCARD, READ, DENY)
> new StandardAcl(TOPIC, "foobar", LITERAL, "User:alice", WILDCARD, READ,
> ALLOW)
> new StandardAcl(TOPIC, "foo", PREFIXED, "User:bob", WILDCARD, READ, ALLOW)
>
> ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true"
>
> AuthorizerContext requestContext = MockAuthorizableRequestContext with
> principal = User:alice
> host = InetAddress.getLocalHost()
>
>
> *Method Call:*
>
> authorizer.authorizeByResourceType(requestContext, READ, TOPIC)
>
> *Question:*
>
> Should the result be true because there is a LITERAL READ ALLOW on "foobar"
> or should the result be false because there is an overriding PREFIXED READ
> DENY on "foo" ?
>
>
>
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren
>