AAP-58794: Enable Lightspeed Service's chatbot API Key authentication.

[romartin]

Jira Issue: https://issues.redhat.com/browse/AAP-58794

Description

Enable Lightspeed Service's chatbot API Key authentication.

Authentication DEPENDS on a new release of lighspeed-stack, which will include lightspeed-core/lightspeed-stack#855

Testing

Tested locally.

Steps to test

1. Run chatbot using api-key authentication module
2. Export the CHATBOT_API_KEY
3. Run wisdom-service
4. Consume the chatbot query / streaming query endpoitns.

Type of Change

• Bug fix (non-breaking change fixing an issue)
• New feature (non-breaking change adding functionality)
• Breaking change (fix or feature causing existing functionality to break)
• Security fix
• Performance improvement
• Code refactoring
• Documentation update
• CI/CD update

Backport Policy

This change should be:

• Not backported - main/master only
• Backported to specific releases (add labels after merge)

Production deployment

• This code change is ready for production on its own
• This code change requires the following considerations before going to production:
  REQUIRES CHATBOT_API_KEY set as ENV

[manstis]

@ldjebran IIRC doesn't the MCP Header support we added handle passing the authentication token?

[romartin]

@manstis @ldjebran

The MCP authentication header (AAP JWT) is being "just forwarded" to AAP, but not really being handled by lightspeed-stack / llama-stack, neither for auth or autz.

This PR work is for enabling some basic api-key authentication mechanism for "our" Ansible lightspeed-stack / llama-stack itself. MCP and authorization here are not in scope as well.

We already considered using the JWT token given after AAP authentication, as wisdom service does by relying on DAB. But we can't use DAB in lightspeed-stack, and it is fast-api (no django) based. We have already considered also creating a customized "AAP" auth provider in lightspeed-stack, but don't like adding "strong" AAP dependencies or related logic implementaion. Also considered using the JWKS authentication provider, which I like the most, but imply more changes. Also we don't need for now a self-contained token with payload user information, we are not adding new features that rely on authenticated users, just ensuring a security mechanism exist in our chatbot stack service.

Anyway, please see more detail on these, and another concerns about using tje AAP JWT token for auth (such as upstream/cloud version), in comments in AAP-50670.

So finally, as a team, decided to implement a basic api-key (Bearer) token authentication mechanism for now... :)

[ldjebran]

@romartin I think you you will need to reopen your PR by pushing to this project branch and not to your private fork repo so that the CI can succeed.

[romartin]

Re-opened in #1794