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
I encountered an issue in the WSO2 API Platform for Kubernetes (APK) where, after deleting a token issuer, previously issued tokens continue to grant access to APIs. This behavior persists until the gateway runtime pods are manually restarted, suggesting a potential caching problem.
Steps to Reproduce
Deploy an API within an organization.
Configure and deploy a token issuer using Keycloak or another external IdP on the cluster.
Obtain an access token from the IdP and successfully invoke the deployed API using this token.
Delete the token issuer from APK.
Attempt to invoke the API again using the previously obtained token.
Observed Behavior:
After deleting the token issuer, the expectation was that the previously issued token would become invalid, and API invocations using this token would fail. However, the API continued to accept the token and process requests successfully.
Additional Observations:
Manual Intervention: Manually deleting the gateway runtime pods (forcing the deployment to spawn new pods) resulted in the expected behavior. Subsequent API invocations with the same token failed, indicating the token was recognized as invalid.
Recreating the Token Issuer: After recreating the token issuer in APK, obtaining a new token from Keycloak allowed successful API invocations, as expected.
Conclusion:
This behavior suggests that the gateway runtime does not immediately recognize the deletion of a token issuer, potentially due to caching mechanisms. Manual pod deletion appears to clear the cache, aligning the system's behavior with expectations.
Recommendation:
Investigate the caching mechanisms within the gateway runtime concerning token issuer configurations. Implementing a cache invalidation process upon the deletion of a token issuer would ensure that tokens from deleted issuers are promptly recognized as invalid, maintaining the integrity of the API security model.
This issue impacts the reliability of token validation post-token issuer deletion and requires attention to ensure consistent security enforcement.
Description
I encountered an issue in the WSO2 API Platform for Kubernetes (APK) where, after deleting a token issuer, previously issued tokens continue to grant access to APIs. This behavior persists until the gateway runtime pods are manually restarted, suggesting a potential caching problem.
Steps to Reproduce
Observed Behavior:
After deleting the token issuer, the expectation was that the previously issued token would become invalid, and API invocations using this token would fail. However, the API continued to accept the token and process requests successfully.
Additional Observations:
Conclusion:
This behavior suggests that the gateway runtime does not immediately recognize the deletion of a token issuer, potentially due to caching mechanisms. Manual pod deletion appears to clear the cache, aligning the system's behavior with expectations.
Recommendation:
Investigate the caching mechanisms within the gateway runtime concerning token issuer configurations. Implementing a cache invalidation process upon the deletion of a token issuer would ensure that tokens from deleted issuers are promptly recognized as invalid, maintaining the integrity of the API security model.
This issue impacts the reliability of token validation post-token issuer deletion and requires attention to ensure consistent security enforcement.
Affected Component
Enforcer
Version
1.2.0
Environment Details (with versions)
OpenShift version: 4.16.18
Kubernetes version: v1.29.8+632b078
Channel: stable-4.16
Relevant Log Output
No response
Related Issues
No response
Suggested Labels
gateway enforcer pod tokenissuer
The text was updated successfully, but these errors were encountered: