You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Relevant aspects (from discussion with Tilo on 2024-11-29):
Create an APISIX route: APISIX shall only trigger authentication and provide a JWT to the backend. Authorization is handled by the backend.
The Resource Health BB allows a user to configure health checks that run repeatedly (as health check task) without the user being logged in. It is intended to use the offline token feature of OIDC in order to allow health check tasks to act on behalf of the original user. It has to be examined if this is easily possible or if it has any unwanted implications. E.g., in order to use offline tokens, users must be assigned the offline-token scope, and the client has to request this scope during the authentication process. It is unclear how this works in conjunction with APISIX-route-based authentication.
The Resource Health BB allows users to create health checks using a CLI. This CLI should also be integratable into a CI/CD pipeline in order to configure predefined health checks on behalf of a user. The challenge here is to provide the user identity to the CLI. The legacy approach of simply storing a username and password would work, but is not really an option. Offline tokens could work in principle, but they are not a durable solution as they expire after some time. So some other feasible solution or a viable comprimise needs to be found.
The text was updated successfully, but these errors were encountered:
Relevant aspects (from discussion with Tilo on 2024-11-29):
Create an APISIX route: APISIX shall only trigger authentication and provide a JWT to the backend. Authorization is handled by the backend.
The Resource Health BB allows a user to configure health checks that run repeatedly (as health check task) without the user being logged in. It is intended to use the offline token feature of OIDC in order to allow health check tasks to act on behalf of the original user. It has to be examined if this is easily possible or if it has any unwanted implications. E.g., in order to use offline tokens, users must be assigned the offline-token scope, and the client has to request this scope during the authentication process. It is unclear how this works in conjunction with APISIX-route-based authentication.
The Resource Health BB allows users to create health checks using a CLI. This CLI should also be integratable into a CI/CD pipeline in order to configure predefined health checks on behalf of a user. The challenge here is to provide the user identity to the CLI. The legacy approach of simply storing a username and password would work, but is not really an option. Offline tokens could work in principle, but they are not a durable solution as they expire after some time. So some other feasible solution or a viable comprimise needs to be found.
The text was updated successfully, but these errors were encountered: