Allow dynamic authorization headers for OpenAI + Azure OpenAI

[csotiriou]

This allows configuring the Azure OpenAI authorization headers on the fly, by instantiating named beans and implementing an interface.

The concept is that the developer can create a bean like this:

@ApplicationScoped
@ModelName("my-model-name") //you can omit this if you have only one model or if you want to use the default model
public class TestClass implements OpenAiRestApi.AuthProvider {
    @Inject MyTokenProviderService tokenProviderService;

    @Override
    public String getAuthorization(Input input) {
        return "Bearer " + tokenProviderService.getToken();
    }
}

One can create beans on a per-configuration scenario using the @Named annotation.

Use case

This will allow using Azure OpenAI integration in complex environments where IAM policies and short-lived Azure tokens are used. In such scenarios, the tokens need to be refreshed periodically using custom security policies, thereby needing such solutions.

[geoand]

We should probably stick with either configName or modelName

[csotiriou]

nice catch. I would prefer sticking with configName since modelName is taken by something else during the setup of the ImageModel.

[geoand]

I would prefer this be done without streams

[geoand]

I like this a lot!

I made some small comments.
We should also add some documentation about the feature

[sberyozkin]

@csotiriou By the way, is #634 relevant ? It you don't use any of the quarkus extensions related to oidc or jwt then it won't be relevant, otherwise it should be... In #634 I'd like to verify that OIDC authorization code flow token can be used, but if the OIDC bearer tokens are already coming in then #634 should take care of them, as long as quarkus-oidc or quarkus-smallrye-jwt verifies them

[sberyozkin]

FYI, I'm not suggesting in anyway that #634 might be a better solution, as I can imagine these tokens may be coming via different channels altogether, so having a dedicated dynamic authorization support is nice on its own.

[geoand]

Let's figure it out

[csotiriou]

@sberyozkin @geoand I just saw #634, I hadn't noticed it! My apologies.

My PR relies in also setting up filters for the OpenAI client. However, it allows for more customization options (more generic implementation) which for some people with very strict security rules and diverse ecosystems is necessary. My PR also allows customization on a per-config-name basis, which is also a requirement for me (and I suspect others in the future combining models and installations).

My suggestion would be to have the mechanism in my PR as the basis for the flexibility of customization it offers. #634 could then use this mechanism to provide an additional module based on the mechanism of this PR.

Further explanation

(examples of use cases)
For example, you may be forced to work behind a proxy managing the authentication itself with rotating keys (custom authentication mechanism towards the proxy), or when using IAM on a cloud provider, you may also rely on mounted secrets (changing each X minutes!) inside the pod. A notable example of this (which is not my use case, but it shows how diverse the IAM world can be) is the way AWS may handle IAM inside a pod with their SDK: https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/auth/WebIdentityTokenCredentialsProvider.html - this reads a mounted file from the disk, which contains the secret you need to use, and it's changing during runtime.

My use case is even more complex, relying on connecting IAM worlds from two cloud providers to actually retrieve a short lived token - falling well outside of the OIDC libraries scope. Depending on the enterprise security guidelines of some major companies, mechanisms such as this are not unheard of.

I believe the above applies to all major cloud providers, it's just that I am able to test (and am familiar with) the Azure internals nowadays...

[sberyozkin]

@csotiriou Thanks for the nice explanation, makes total sense to have a generic dynamic mechanism in place to support various dynamic token inputs, beyond the typical standard ones.

I was thinking a bit if such filters should also work for other providers, like vertex-gemini, but it can complicate things with issues like which filter applies to which provider, if the new interface would be in the core module, as it would require a named model support similarly to how it is done for AI services.

As far as #634 is concerned, I hope, if that is proven to work and agreed it makes sense, that it will be free for users, i.e, they won't have to write and register custom dynamic filter. I'll CC you there as well to discuss things related to that PR further

Thanks

[csotiriou]

I made a rename there, and added some documentation in the OpenAI section.

I'm currently contemplating adding more power to the developer by changing the

interface AuthProvider {
    String getAuthorization();
}

to

interface AuthProvider {
    String getAuthorization(String method, URI url, MultivaluedMap<String, String> headers);
}

Haven't decided yet, just wanted to ask. The thought is that in the scope of the named model one may want to differentiate the authentication behaviour per deployment or by things passed as headers. The deployment name is not passed in this context but it is inferrable via the request URI.

Not sure about this, yet, though, what do you think?

[geoand]

I am +1 for adding the more "powerfull" version, however I would write it like this:

interface AuthProvider {
    String getAuthorization(Input input);

    interface Input {
       String getMethod();
 
       ...
    }
}

This way we can add stuff in the future without breaking the method signature

[geoand]

Awesome!

I just added one last comment