Last Modified: Dec 18, 2024
Affected Product(s):
BIG-IP APM
Known Affected Versions:
15.0.0, 15.0.1, 15.0.1.1, 15.0.1.2, 15.0.1.3, 15.0.1.4, 15.1.0, 15.1.0.1, 15.1.0.2, 15.1.0.3, 15.1.0.4, 15.1.0.5, 15.1.1, 15.1.2, 15.1.2.1, 15.1.3, 15.1.3.1, 15.1.4, 15.1.4.1, 15.1.5, 15.1.5.1, 15.1.6, 15.1.6.1, 15.1.7, 15.1.8, 15.1.8.1, 15.1.8.2, 15.1.9, 15.1.9.1, 15.1.10, 15.1.10.2, 15.1.10.3, 15.1.10.4, 15.1.10.5, 15.1.10.6, 16.1.0, 16.1.1, 16.1.2, 16.1.2.1, 16.1.2.2, 16.1.3, 16.1.3.1, 16.1.3.2, 16.1.3.3, 16.1.3.4, 16.1.3.5, 17.0.0, 17.0.0.1, 17.0.0.2
Fixed In:
17.1.1, 16.1.4
Opened: Nov 28, 2022 Severity: 4-Minor
The Claim Validation in OAuth Scope Fails when two Azure providers with different tenant ID are provided in the JWT provider list such that, the non-expected provider comes first and expected one comes later. Once failure is logged OAuth flow is redirected to Deny Page.
The policy rule displays the deny page.
When the list of providers are sent to TMM for Signature Validation the invalid provider is sent back as response indicating that it has passed the signature validation for the access_token that has been acquired in previous steps. There are chances where Azure as AS might be using same key ID (kid) for different tenants, so in such cases even the invalid provider passes the signature validation. In general practice, Claim Validation Comes after Signature Validation, when the invalid provider is sent back from TMM it fails Claim Validation in APMD.
None
None