Access Troubleshooting: BIG-IP APM OIDC integration
Table of Contents
Introduction
Troubleshooting Access use cases can be challenging due to the interconnected components used to achieve such use cases.
A simple example for Active Directory authentication can go through below challenges,
- DNS resolution of Domain Controller (DC) configured.
- Reachability between F5 and DC.
- Communication ports used.
- Domain account privileges.
Looking at the issue of non-working Active Directory (AD) authentication is a complex task, yet looking at each component to verify the functionality is much easier and shows output the influence further troubleshooting actions.
Implementation and troubleshooting
We discussed the implementation of OpenID Connect over here
Let's discuss here how we can troubleshoot issues in OIDC implementation, here's a summary of the main points we are checking
|
Role |
Troubleshooting main points |
|
OAuth Authorization Server |
DNS resolution for the authentication destination. |
|
OAuth Client |
DNS resolution for the authorization server. Routing setup. |
|
OAuth Resource Server |
Token settings. |
Looking at the main points, you can see the common areas we need to check while troubleshooting OAuth / OIDC solutions, below are the troubleshooting approach we are following,
- Check the logs.
- APM logging provides a comprehensive set of logs, the main logs to be checked apm, ltm and tmm.
- DNS resolution and check DNS resolver settings.
- Routing setup.
- Authentication methods settings.
- OAuth settings and parameters.
Check the logs
The logs are your true friends when it comes to troubleshooting.
- We start by creating debug logging profile Overview > Event logs > Setting.
- Select the target Access Policy to apply the debug profile.
Case 1: Connection reset after authentication
In this case the below is the connection sequence,
- User accessing through F5 acting as Client + RS.
- Users are redirected to OAuth provider for authentication.
- User is redirected back to F5 but connection resets at this point.
Troubleshooting steps:
- Checking logs by clicking the session ID from Access > Overview.
- From the below logs we can see the logon was successful but somehow the Authorization code wasn’t detected.
- One main reason would be mismatched settings between Auth server and Client configurations.
- In our setup I’m using provider flow type as Hybrid and format code-idtoken.
Local Time
2024-06-11 06:47:48
Log Message
/Common/oidc_google_t1.app/oidc_google_t1:Common:204adb19: Session variable 'session.logon.last.result' set to '1'
Partition
Common
Local Time
2024-06-11 06:47:49
Log Message
/Common/oidc_google_t1.app/oidc_google_t1:Common:204adb19: Authorization code not found.
Partition
Common- Checking back the configuration to validate the needed flow type: adjust flow type at the provider settings to be Authorization Code instead of Hybrid.
Case 2: Expired JWT Keys
In this case the below is the connection sequence,
- User accessing through F5 acting as Client + RS.
- Users are redirected to OAuth provider for authentication.
- User is redirected back to F5 with Access denied.
Troubleshooting steps:
- Checking logs by clicking the session ID from Access > Overview.
- From the below logs we can see the logon was successful but somehow the Authorization code wasn’t detected.
- One main reason can be the need to rediscover JWT keys.
Local Time
2024-06-11 06:51:06
Log Message
/Common/oidc_google_t1.app/oidc_google_t1:Common:848f0568: Session variable 'session.oauth.client.last.errMsg' set to 'None of the configured JWK keys match the received JWT token, JWT Header: eyJhbGciOiJSUzI1NiIsImtpZCI6ImMzYWJlNDEzYjIyNjhhZTk3NjQ1OGM4MmMxNTE3OTU0N2U5NzUyN2UiLCJ0eXAiOiJKV1QifQ'
Partition
Common
The action to be taken would be to rediscover the JWT keys if they are automatic or add the new one manually.
- Head to Access ›› Federation : OAuth Client / Resource Server : Provider
- Select the created provider.
- Click Discover to fetch new keys from provider
- Save and apply the new policies settings.
Case 3: OAuth Client DNS resolver failure
In this case the below is the connection sequence,
- User accessing through F5 acting as Client + RS.
- Users are redirected to OAuth provider for authentication.
- User is redirected back to F5 with Access denied.
Troubleshooting steps:
- Checking logs by clicking the session ID from Access > Overview.
- From the below logs we can see the logon was successful but somehow the Authorization code wasn’t detected.
- Another reason for such behavior can be the DNS failure to reach to OAuth provider to validate JWT keys.
Local Time
2024-06-12 19:36:12
Log Message
/Common/oidc_google_t1.app/oidc_google_t1:Common:fb5d96bc: Session variable 'session.oauth.client.last.errMsg' set to 'HTTP error 503, DNS lookup failed'
Partition
Common
- Checking DNS resolver Network ›› DNS Resolvers : DNS Resolver List
- Validate resolver config. is correct.
- Check route to DNS server Network ›› Routes
Note, DNS resolver uses TMM traffic routes not the management plane system routing.
Case 4: Token Mismatch
In this case the below is the connection sequence,
- User accessing through F5 acting as Client + RS.
- Users are redirected to OAuth provider for authentication.
- User is redirected back to F5 with Access denied.
Troubleshooting steps:
- Checking logs by clicking the session ID from Access > Overview.
- We will find the logs showing Bearer token is received yet no token enabled at the client / resource server connections.
Local Time
2024-06-21 07:25:12
Log Message
/Common/f5_local_client_rs.app/f5_local_client_rs:Common:c224c941: Session variable 'session.oauth.client./Common/f5_local_client_rs.app/f5_local_client_rs_oauthServer_f5_local_provider.token_type' set to 'Bearer'
Partition
Common
Local Time
2024-06-21 07:25:12
Log Message
/Common/f5_local_client_rs.app/f5_local_client_rs:Common:c224c941: Session variable 'session.oauth.scope./Common/f5_local_client_rs.app/f5_local_client_rs_oauthServer_f5_local_provider.errMsg' set to 'Token is not active'
Partition
Common
- We need to make sure client and resource server have JWT token enabled instead of opaque and proper JWT token is selected.
Case 5: Audience mismatch
In this case the below is the connection sequence,
- User accessing through F5 acting as Client + RS.
- Users are redirected to OAuth provider for authentication.
- User is redirected back to F5 with Access denied.
Troubleshooting steps:
- Checking logs by clicking the session ID from Access > Overview.
- We will find the logs stating incorrect or unmatched audience.
Local Time
2024-06-23 21:32:42
Log Message
/Common/f5_local_client_rs.app/f5_local_client_rs:Common:42ef6c51: Session variable 'session.oauth.scope.last.errMsg' set to 'Audience not found : Claim audience= f5local JWT_Config Audience='
Partition
Common
Case 6: Scope mismatch
In this case the below is the connection sequence,
- User accessing through F5 acting as Client + RS.
- Users receive authorization error with wrong scope.
Troubleshooting steps:
- Checking logs by clicking the session ID from Access > Overview.
- Scope name is mentioned in the logs, in this case I named it “wrongscope”
- You will see scope includes openid string, this is because we have openid enabled.
- Change the scope to the one configured at the provider side.
Local Time
2024-06-24 06:20:28
Log Message
/Common/oidc_google_t1.app/oidc_google_t1:Common:edacbe31:/Common/oidc_google_t1.app/oidc_google_t1_act_oauth_client_0_ag: OAuth: Request parameter 'scope=openid wrongscope'
Partition
Common
Case 7: Incorrect JWT Signature
In this case the below is the connection sequence,
- User accessing through F5 acting as Client + RS.
- Users are redirected to OAuth provider for authentication.
- User is redirected back to F5 with Access denied.
Troubleshooting steps:
- Checking logs by clicking the session ID from Access > Overview.
- We will find the logs showing Bearer token is received yet no token enabled at the client / resource server connections.
Local Time
2024-06-21 07:25:12
Log Message
/Common/f5_local_client_rs.app/f5_local_client_rs:Common:c224c941: Session variable 'session.oauth.scope./Common/f5_local_client_rs.app/f5_local_client_rs_oauthServer_f5_local_provider.errMsg' set to 'Token is not active'
Partition
Common
- When trying to renew the JWT key we see this error in the GUI.
An error occurred:
Error in processing URL https://accounts.google.com/.well-known/openid-configuration. The message is - javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
- We need at this step to validate the used CA bundle and if we need to allow the trust of expired or self-signed JWT tokens.
General issues
In addition to the listed cases above, we have some general issues:
- DNS failure at client side not able to reach whether the F5 virtual server or OAuth provider to provide authentication information.
- In this case, please verify DNS configurations and Network setup on the client machine.
- Validate HTTP / SSL / TCP profiles at the virtual server are correctly configured.
Related Content
- DNS Resolver Overview
- BIG-IP APM deployments using OAuth/OIDC with Microsoft Azure AD may fail to authenticate
- OAuth and OpenID Connect - Made easy with Access Guided Configurations templates
- Request and validate OAuth / OIDC tokens with APM
- F5 APM OIDC with Azure Entra AD
- Configuring an OAuth setup using one BIG-IP APM system as an OAuth authorization server and another as the OAuth client
Published Jul 08, 2024
Version 1.0
