Access Troubleshooting: BIG-IP APM OIDC integration

 

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. 
Routing setup to the authentication system. 
Authentication configurations and settings. 
Scope settings.
Token signing and settings.

OAuth Client 

DNS resolution for the authorization server. 

Routing setup. 
Token settings.
Authorization attributes and parameters. 

OAuth Resource Server

Token settings.
Scope 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, 

  1. Check the logs. 
    1. APM logging provides a comprehensive set of logs, the main logs to be checked apm, ltm and tmm.
  2.  DNS resolution and check DNS resolver settings.
  3.  Routing setup. 
  4. Authentication methods settings. 
  5. 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

Published Jul 08, 2024
Version 1.0
  • we are using f5 APM V17 in APM we have- session inactivity timeout  - 15mins after reaching 15mins, if we enter browser displaying default F5 page - vdesk/hangup.php3 *expectation - upon reaching 15mins, it should automatically redirect to landing page. How to do this can someone give me some idea?

    • momahdy's avatar
      momahdy
      Icon for Employee rankEmployee

      Hi sinum
      The intention of such URI is to clear user session as you mentioned due to the timeout value, you ca use this iRule to change this URI to the main one. 

      when CLIENT_ACCEPTED {
      ACCESS::restrict_irule_events disable
      }
      
          when HTTP_REQUEST {
      
          if { [HTTP::uri] equals "/vdesk/hangup.php3" } {
              ACCESS::session remove
              HTTP::redirect "/"
          }
          }
      

      let me know how it goes. 

      • sinum's avatar
        sinum
        Icon for Altostratus rankAltostratus

        Thanks for the response, but this is based on http trigger, is there any way to redirect automatically landinguri instead of waiting for client action ?