Forum Discussion

sricharan61's avatar
sricharan61
Icon for Cirrus rankCirrus
Feb 12, 2020

how to have F5 APM send a 401 status code back instead of a 200 for the failed oAuth login attempts

how to have F5 APM send a 401 status code back instead of a 200 for the failed oAuth login attempts with /vdesk/hangup.php3 page as a response. The client needs a 401 for the failed attempts as the client is an application that uses that status message to realize the credentials did not work and correct them for the next attempt.

 

When I tried to use an irule based on the DENY result being triggered for the oAuth client failed branch, using an irule with "ACCESS::session result equals DENY" option, with this in the irule

 

HTTP::respond 401 WWW-Authenticate "Basic realm=\"Service\""

 

i get this error

 

err tmm[18432]: 01220001:3: TCL error: /Common/irule_test_401 <ACCESS_POLICY_COMPLETED> - Unsupported option: result (line 2)   invoked from within "ACCESS::session result", with

 

 

 

If i try an ACCESS_POLICY_AGENT_EVENT trigger at the oAuth fail branch and use that to serve a 401 response using irule as

 

HTTP::respond 401 WWW-Authenticate "Basic realm=\"Service\""

 

i get this error

 

err tmm[18432]: 011f0007:3: http_process_state_prepend - Invalid action:0x10a0c1 clientside (x.x.x.x:63428 -> y.y.y.y:443) ((null connflow)) (Client side: vip=/Common/vs_testvip_443 profile=http pool=/Common/pool_testvip_443 client_ip=x.x.x.x)

 

 

application delivery
BIG-IP Access Policy Manager (APM)

4 Replies

Sort By
  • Yoann_Le_Corvi1's avatar
    Yoann_Le_Corvi1
    Icon for Cumulonimbus rankCumulonimbus
    Feb 14, 2020

    Hi

     

    Have you tried ACCESS::respond instead of HTTP::respond ?

     

    I do not have the possibility right now to test your use case, but that is something to try,.

     

    Yoann

    • sricharan61's avatar
      sricharan61
      Icon for Cirrus rankCirrus
      Feb 14, 2020

      Hi Yoann

       

      ACCESS::respond worked , but it works for only the first attempt, if the client tries the same wrong credentials in the next atttempt, i see the 401 is again replaced with the /vdesk/hangup page. This is the irule i have now.

       

      when ACCESS_POLICY_COMPLETED {

      set errormessage [ACCESS::session data get "session.oauth.client.last.errMsg"]

       

      if { 

        $errormessage contains "HTTP error 400, Error: invalid_grant: AADSTS50126: Error validating credentials due to invalid username or password"}{

        ACCESS::respond 401 WWW-Authenticate "Basic realm=\"Service\""

        log local0. "401 response if loop triggered"

        }

        else

        {

        log local0. "401 response if loop not triggered"

        }

      }

       

      If we can make that work for all attempts with wrong creds that should be it.

       

       

       

       

       

      Here are the policy logs for the first and the second calls seperated out with a few empty lines.

       

      Feb 14 09:58:24 f5-sca-vcmp-bastion-01 info apmd[12729]: 01490007:6: /Common/headerauthaccprofile_Servicedev:Common:216081c7: Session variable 'session.oauth.client./Common/headerauthaccprofile_Servicedev_act_oauth_client_ag.errMsg' set to 'HTTP error 400, Error: invalid_grant: AADSTS50126: Error validating credentials due to invalid username or password. Trace ID: c21efb57-a7a9-431a-8d20-ca9cb8552c00 Correlation ID: 31097609-ee17-4b60-8988-c45b2b98d1ec Timestamp: 2020-02-14 15:58:24Z'

      Feb 14 09:58:24 f5-sca-vcmp-bastion-01 info apmd[12729]: 01490007:6: /Common/headerauthaccprofile_Servicedev:Common:216081c7: Session variable 'session.oauth.client./Common/headerauthaccprofile_Servicedev_act_oauth_client_ag.validated' set to '0'

      Feb 14 09:58:24 f5-sca-vcmp-bastion-01 info apmd[12729]: 01490007:6: /Common/headerauthaccprofile_Servicedev:Common:216081c7: Session variable 'session.oauth.client./Common/testb2b.authresult' set to '0'

      Feb 14 09:58:24 f5-sca-vcmp-bastion-01 info apmd[12729]: 01490007:6: /Common/headerauthaccprofile_Servicedev:Common:216081c7: Session variable 'session.oauth.client./Common/testb2b.errMsg' set to 'HTTP error 400, Error: invalid_grant: AADSTS50126: Error validating credentials due to invalid username or password. Trace ID: c21efb57-a7a9-431a-8d20-ca9cb8552c00 Correlation ID: 31097609-ee17-4b60-8988-c45b2b98d1ec Timestamp: 2020-02-14 15:58:24Z'

      Feb 14 09:58:24 f5-sca-vcmp-bastion-01 info apmd[12729]: 01490007:6: /Common/headerauthaccprofile_Servicedev:Common:216081c7: Session variable 'session.oauth.client./Common/testb2b.validated' set to '0'

      Feb 14 09:58:24 f5-sca-vcmp-bastion-01 info apmd[12729]: 01490007:6: /Common/headerauthaccprofile_Servicedev:Common:216081c7: Session variable 'session.oauth.client.last.authresult' set to '0'

      Feb 14 09:58:24 f5-sca-vcmp-bastion-01 info apmd[12729]: 01490007:6: /Common/headerauthaccprofile_Servicedev:Common:216081c7: Session variable 'session.oauth.client.last.errMsg' set to 'HTTP error 400, Error: invalid_grant: AADSTS50126: Error validating credentials due to invalid username or password. Trace ID: c21efb57-a7a9-431a-8d20-ca9cb8552c00 Correlation ID: 31097609-ee17-4b60-8988-c45b2b98d1ec Timestamp: 2020-02-14 15:58:24Z'

      Feb 14 09:58:24 f5-sca-vcmp-bastion-01 info apmd[12729]: 01490007:6: /Common/headerauthaccprofile_Servicedev:Common:216081c7: Session variable 'session.oauth.client.last.validated' set to '0'

      Feb 14 09:58:24 f5-sca-vcmp-bastion-01 info apmd[12729]: 01490007:6: /Common/headerauthaccprofile_Servicedev:Common:216081c7: Session variable 'session.policy.result' set to 'deny'

      Feb 14 09:58:24 f5-sca-vcmp-bastion-01 info apmd[12729]: 01490007:6: /Common/headerauthaccprofile_Servicedev:Common:216081c7: Session variable 'session.rest.clearcache' set to '0'

      Feb 14 09:58:24 f5-sca-vcmp-bastion-01 info apmd[12729]: 01490007:6: /Common/headerauthaccprofile_Servicedev:Common:216081c7: Session variable 'session.rest.groupname' set to ''

      Feb 14 09:58:24 f5-sca-vcmp-bastion-01 info apmd[12729]: 01490007:6: /Common/headerauthaccprofile_Servicedev:Common:216081c7: Session variable 'session.rest.requestdomain' set to ''

      Feb 14 09:58:24 f5-sca-vcmp-bastion-01 info apmd[12729]: 01490007:6: /Common/headerauthaccprofile_Servicedev:Common:216081c7: Session variable 'session.rest.requesttype' set to ''

      Feb 14 09:58:24 f5-sca-vcmp-bastion-01 info apmd[12729]: 01490007:6: /Common/headerauthaccprofile_Servicedev:Common:216081c7: Session variable 'session.rest.username' set to ''

      Feb 14 09:58:24 f5-sca-vcmp-bastion-01 debug apmd[12729]: 01490266:7: /Common/headerauthaccprofile_Servicedev:Common:216081c7: ApmD.cpp: 'sendAccessPolicyResponse()': 2683: DONE WITH ACCESS POLICY - send 'we are done with access policy for this session' code

      Feb 14 09:58:24 f5-sca-vcmp-bastion-01 debug apmd[12729]: 01490266:7: /Common/headerauthaccprofile_Servicedev:Common:216081c7: ApmD.cpp: 'process_apd_request()': 1835: ** done with the request processing **

       

       

       

       

       

       

       

       

       

       

       

       

       

       

      Feb 14 09:58:34 f5-sca-vcmp-bastion-01 info tmm[18432]: 01870003:6: /Common/headerauthaccprofile_Servicedev:Common:00000000: Agent created variable name: perflow.client.ip.address, value: 10.2.142.225

      Feb 14 09:58:34 f5-sca-vcmp-bastion-01 info tmm[18432]: 01870003:6: /Common/headerauthaccprofile_Servicedev:Common:00000000: Agent created variable name: perflow.client.port, value: 59545

      Feb 14 09:58:34 f5-sca-vcmp-bastion-01 info tmm[18432]: 01870003:6: /Common/headerauthaccprofile_Servicedev:Common:00000000: Agent created variable name: perflow.server.ip.address, value: 10.118.13.48

      Feb 14 09:58:34 f5-sca-vcmp-bastion-01 info tmm[18432]: 01870003:6: /Common/headerauthaccprofile_Servicedev:Common:00000000: Agent created variable name: perflow.server.port, value: 443

      Feb 14 09:58:34 f5-sca-vcmp-bastion-01 info tmm[18432]: 01870003:6: /Common/headerauthaccprofile_Servicedev:Common:00000000: Agent created variable name: perflow.ssl.bypass_default, value: 0

      Feb 14 09:58:34 f5-sca-vcmp-bastion-01 info tmm[18432]: 01870003:6: /Common/headerauthaccprofile_Servicedev:Common:00000000: Agent created variable name: perflow.client.ip.address, value: 10.2.142.225

      Feb 14 09:58:34 f5-sca-vcmp-bastion-01 info tmm[18432]: 01870003:6: /Common/headerauthaccprofile_Servicedev:Common:00000000: Agent created variable name: perflow.client.port, value: 59546

      Feb 14 09:58:34 f5-sca-vcmp-bastion-01 info tmm[18432]: 01870003:6: /Common/headerauthaccprofile_Servicedev:Common:00000000: Agent created variable name: perflow.server.ip.address, value: 10.118.13.48

      Feb 14 09:58:34 f5-sca-vcmp-bastion-01 info tmm[18432]: 01870003:6: /Common/headerauthaccprofile_Servicedev:Common:00000000: Agent created variable name: perflow.server.port, value: 443

      Feb 14 09:58:34 f5-sca-vcmp-bastion-01 info tmm[18432]: 01870003:6: /Common/headerauthaccprofile_Servicedev:Common:00000000: Agent created variable name: perflow.ssl.bypass_default, value: 0

      Feb 14 09:58:34 f5-sca-vcmp-bastion-01 notice tmm[18432]: 01490567:5: /Common/headerauthaccprofile_Servicedev:Common:216081c7: Session deleted (policy_result).

      Feb 14 09:58:34 f5-sca-vcmp-bastion-01 notice tmm[18432]: 01490567:5: /Common/headerauthaccprofile_Servicedev:Common:216081c7: Session deleted (policy_result).

      Feb 14 09:58:50 f5-sca-vcmp-bastion-01 notice tmm[18432]: 01490521:5: /Common/headerauthaccprofile_Servicedev:Common:44938aba: Session statistics - bytes in: 0, bytes out: 0

      Feb 14 09:58:50 f5-sca-vcmp-bastion-01 notice tmm[18432]: 01490521:5: /Common/headerauthaccprofile_Servicedev:Common:44938aba: Session statistics - bytes in: 0, bytes out: 0

       

       

      The second attempt is not generating that trigger event which is the error message i am looking for in the irule. We may need to find another matching condition to get this to work for all attempts with wrong creds

  • Yoann_Le_Corvi1's avatar
    Yoann_Le_Corvi1
    Icon for Cumulonimbus rankCumulonimbus
    Feb 17, 2020

    Hi

    Yep that is normal. Once the session is established you do not go though it again.

    Maybe try to kill the session as well after the RESPOND 

    ACCESS::session remove

    Like this the authentication will need to be redone at next attempt

    Or try to switch to per request policy ?

    Let us know how it goes

    • sricharan61's avatar
      sricharan61
      Icon for Cirrus rankCirrus
      Feb 18, 2020

      It works with the ACCESS::session remove, thanks for the help 😊 .

      I would want to use the session for this instead of request, as per-request would cost more to authenticate users with azure on every attempt, which is not a requirement presented to us so far.