Feature request, make it possible to override auth providers

[SvenMarquardt5772]

The default generated auth providers, expect the tokens and username in properties. But I want to get them from the secrets manager of aws or gcp for example.

To get them inside the property store is difficult, and it would be easier, if I could override the implementation of the classes AuthenticationPropagationHeadersFactory,CompositeAuthenticationProvider.

It is difficult because, even with a custom property provider, you can't inject the SecretsManagerClient because property runs too early.

So, a property that I can set with the full class name would be enough for this feature.

[SvenMarquardt5772]

As a workaorund, i currently use this maven plugin.

<plugin>
                <groupId>com.google.code.maven-replacer-plugin</groupId>
                <artifactId>replacer</artifactId>
                <version>1.5.3</version>
                <executions>
                    <execution>
                        <phase>prepare-package</phase>
                        <goals>
                            <goal>replace</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <basedir>${project.build.directory}/generated-sources</basedir>
                    <filesToInclude>**/*.java</filesToInclude>
                    <replacements>
                        <replacement>
                            <token>import org.openapi.quarkus.swagger_v3_v3_json.api.auth.CompositeAuthenticationProvider</token>
                            <value>import <package_name>.CompositeAuthenticationProvider</value>
                        </replacement>
                        <replacement>
                            <token>import org.openapi.quarkus.swagger_v3_v3_json.api.auth.AuthenticationPropagationHeadersFactory</token>
                            <value>import <package_name>.AuthenticationPropagationHeadersFactory</value>
                        </replacement>
                    </replacements>
                </configuration>
            </plugin>

[jhaakma]

As a workaorund, i currently use this maven plugin

@SvenMarquardt5772 Any idea how to get this thing to trigger when running mvn quarkus:dev? The damn this recompiles and recreates the target files, but doesn't run the replacer even if I set the phase to compile.

[SvenMarquardt5772]

@jhaakma you have to use the correct phases as well for the openapi plugin and put the configs into the executions. Here is my example. And you can only do this for phases so there is no way to trigger the other plugin from quarkus:dev. This is how maven lifecycles work. You have to do a mvn install quarkus:dev so that mvn can see, that everything is already compiled.

   <plugin>
                <groupId>com.google.code.maven-replacer-plugin</groupId>
                <artifactId>replacer</artifactId>
                <version>1.5.3</version>
                <executions>
                    <execution>
                        <id>replace-auth-provider</id>
                        <inherited>false</inherited>
                        <phase>process-resources</phase>
                        <goals>
                            <goal>replace</goal>
                        </goals>
                        <configuration>
                            <basedir>${project.build.directory}/generated-sources</basedir>
                            <filesToInclude>**/*.java</filesToInclude>
                            <replacements>
                                <replacement>
                                    <token>import org.openapi.quarkus.swagger_v3_v3_json.api.auth.CompositeAuthenticationProvider</token>
                                    <value>import ${replacement}</value>
                                </replacement>
                                <replacement>
                                    <token>import org.openapi.quarkus.swagger_v3_v3_json.api.auth.AuthenticationPropagationHeadersFactory</token>
                                    <value>import ${replacement}</value>
                                </replacement>
                            </replacements>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>io.quarkus</groupId>
                <artifactId>quarkus-maven-plugin</artifactId>
                <extensions>true</extensions>
                <executions>
                    <execution>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>build</goal>
                            <goal>generate-code</goal>
                            <goal>generate-code-tests</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

[hbelmiro]

@wmedvede WDYT?

[ricardozanini]

@SvenMarquardt5772

But I want to get them from the secrets manager of aws or gcp for example.

I think the best approach here would be to create a property source from these places and not a custom AuthProvider. Although, I understand that it could be useful to have users replace them in build time.

@hbelmiro we can open an issue to accept custom providers from users and link it here.

[hbelmiro]

@ricardozanini A ConfigSource wouldn't be enough for this particular use case because we can't inject beans in ConfigSources.

As @SvenMarquardt5772 said:

It is difficult because, even with a custom property provider, you can't inject the SecretsManagerClient because property runs too early.

The only solution I can see is creating a custom AuthProvider, but I'd like to have a second opinion like yours or @wmedvede.

[ricardozanini]

@ricardozanini A ConfigSource wouldn't be enough for this particular use case because we can't inject beans in ConfigSources.

@hbelmiro the Configuration would be read by Quarkus in runtime by fetching the giving sources. Why we would need to inject beans? The providers just read from there and add it to the authorization flow.

[hbelmiro]

@ricardozanini

the Configuration would be read by Quarkus in runtime by fetching the giving sources.

Yes. And the given source would need to fetch from SecretsManagerClient, which needs to be injected.

[ricardozanini]

Well, I guess we should evaluate them. Because for use cases like this would be way simpler for users just to add their own ConfigSource and the providers just take from there. I'm not sure if adding custom providers at this stage is a good idea.

[hbelmiro]

@ricardozanini regarding your comment

LOL now that I see that we already support custom providers (not override them)

Yeah, we have a couple of custom providers, but AFAIK users can't create their own. They can only use the ones this extension provides.

[ricardozanini]

IIRC you can create your own and the API would inject it for you during codegen time.

[hbelmiro]

@ricardozanini Yes, it is possible to create custom providers. We even have an example: https://github.com/quarkiverse/quarkus-openapi-generator/blob/main/integration-tests/register-provider/src/main/java/org/acme/openapi/weather/api/provider/CountProvider.java

Nevertheless, I believe that we would have to override the existing one for this particular use case.

[ricardozanini]

I'd rather go for the ConfigSource injection if possible.

[michalsomora]

I would also welcome the option to change ClientHeadersFactory implementation. In my case i would like to stick to default implementation - DefaultClientHeadersFactoryImpl used by @RegisterClientHeaders I need to propagate my custom header param and org.eclipse.microprofile.rest.client.propagateHeaders works exactly as i need.

[andrejpetras]

https://github.com/quarkiverse/quarkus-openapi-generator/pull/365

[hbelmiro]

Closed by: https://github.com/quarkiverse/quarkus-openapi-generator/pull/365