Kevin Wooten

@aaronz-vipaso This is now doable with the new client introduced in 4.+

The interceptor currently assumes all methods need some authorization annotation. To allow a public method currently you can use `FGARelation(FGARelation.ANY)`.

I'm thinking we should change the current behavior in two ways: 1. Add a configuration enables or disable "global" authorization. With it enabled it would mean it works as it...

Both of these are implemented: * Configuration - `quarkus.zanzibar.filter.enabled=false` disabled the filter * Annotation - `@FGARelation(FGARelation.ANY)` on a class/method will selectively disable to the filter.

@raffaelespazzoli @iocanel I'm fairly familiar with gRPC and after doing some brainstorming on Zulip I'm not sure Zanzibar's current annotation based model will work. With HTTP there is a well...

Here's how that would look... ```java public class MyGRPCServiceImpl implements MyGRPCService { @Inject ZanzibarAuthorizer authorizer; // Call using a static relation @FGARelation("owner") Response accessDocuemnt(DocuementAccessRequest request) { // authorize... throwing exception...

Notice how that could be used for HTTP or gRPC. Obviously it would be required for gRPC but HTTP endpoints could use it when they need to dynamically determine the...

Also it appears there is no default authentication handling for gRPC. Clement correctly suggested that gRPC prefers mutual TLS so we need to provide a plugin point where users can...

This might be a better solution for some than requiring defining a command line property (which I always forget 😏). ```kotlin jib { to { image = "..." auth {...}...

+1... I'm wearing out my return key at this point