-
Notifications
You must be signed in to change notification settings - Fork 319
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Filters for OIDC authentication mechanisms #2496
Comments
@arkodg any comments to this one? As I see this is quite important feature to have possibility to use service with human users and machines. |
@zetaab @sadovnikov my hesitance is with including another field like You could implement the same logic (#2425 (reply in thread)) with 2 HTTPRoutes today
This should unblock you for now, but will end up causing some duplicate configuration for you. You could also use a EnvoyPatchPolicy with a A more long term would be to to figure out the right UX / field for this use case. |
@arkodg From my discussion with @zhaohuabing I understood that two HTTP Routes cannot be applied to the same host/path. It seems I read it wrong, it's just necessary to ensure the uniqueness of the "matches" in the routes. We'll give it a try |
This issue has been automatically marked as stale because it has not had activity in the last 30 days. |
here is the example of how it can be used currently https://gist.github.com/zetaab/31b835bfed5bdc7b2a3e29bc6557e3c1 What that does?
However, if its used like this it means that application should have the logic to redirect to /login when its needed to use refresh token / create new token. tl;dr it works but its not pretty |
This issue has been automatically marked as stale because it has not had activity in the last 30 days. |
Description:
Currently, when OIDC and JWT authentication mechanisms are configured in the same
SecurityPolicy
, the OIDC is applied first. It ensures the presence of the bearer and refresh tokens in cookies, and adds theAuthorisation
header to the request. Then JWT is applied, validating the added header.This setup works perfectly for browser requests. However, it prevents monitoring systems and regression tests, which provide a valid
Authorisation
header in the requests, from accessing the services on the same URLs. The OIDC mechanism kicks in first and redirects the requests to the login pages because of the missing cookies.We suggest extending the configuration of, at least, the OIDC mechanism with the possibility of adding a header-based filter.
When implemented, the OIDC can be skipped if the
Authorization
header is present.An example of the configuration:
Envoy Proxy supports Composite Filters, which support such decisions and therefore can be used to implement this functionality.
Relevant Links:
The text was updated successfully, but these errors were encountered: