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 <claude.war...@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 <rajinisiva...@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 > > <claude.war...@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.war...@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.war...@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 < > > rajinisiva...@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 <cla...@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 > > > >>> > > > > >>> > > > >> > > > > > >
