Forum Discussion

Nico_the_other's avatar
Nico_the_other
Icon for Altocumulus rankAltocumulus
Dec 12, 2023

BIGIP OAUTH : Transmit "Application id" to backend server after a successful atuthentication

Hello @ all  🙂 I took over the management of a bigip (15.1.1) on which APM is configured, in particular to do OAUTH for partner applications. I'd like to know if it is possible to transmit used ap...
application delivery
application-id
BIG-IP
oauth
security
  • Lucas_Thompson's avatar
    Lucas_Thompson
    Jan 08, 2024

    Thanks for the extra detail.

    I'd suppose that if your user session is authenticated with APM (the user is sending APM's MRHSession cookie so is associated with an APM session) and the app ID is recorded inside the session, and the user is accessing the backend through APM, all you'd have to do is grab this info and add a header during ACCES_ACL_ALLOWED. This event is fired during each network request from users, and can be used more or less like HTTP_REQUEST.

     

    when ACCESS_ACL_ALLOWED {
      set appid [ACCESS::session data get "session.oauth.authz.client_id"]
      HTTP::header replace "X-PARTNER-ID" $appid
      log "Inserted appid: $appid"
    }

     

Lucas_Thompson's avatar
Lucas_Thompson
Icon for Employee rankEmployee

In that situation, I'd suppose the OAuth Client would be the external app, the OAuth AS would be APM, and the OAuth Resource Server is the "Vserver authenticated by token"?

The standards body that came up with most of OAuth was recently acquired by Okta, and they have a good article about how to think about your grant types and flows here:

https://auth0.com/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use

APM support for the roles of OAuth AS, OAuth Client, and OAuth RS, and a combined role of OAuth RS + OAuth Client is fairly comprehensive and complete, with one important exception: APM's OAuth AS implementation can operate in Opaque or JWT mode, and in JWT mode the APM is *stateless* from the server perspective. In lieu of server-stored state, the state is stored inside the JWT bearer and refresh tokens that are provided to the OAuth Client. This means that your user (or OAuth Client app on the user's behalf) must transmit the JWT on each request. In BIG-IP's Opaque mode, APM *does* keep session state and the user can transmit the standard APM MRHSession cookie for requests to be associated with the user session. This allows a regular browser to behave as if it were an OAuth Client.

Additionally, in Opaque mode, APM does have the "JWT SSO" capability to append a custom JWT on the fly and transmit to an OAuth RS (or any other server). In this way you can combine frontend opaque tokens and backend JWT tokens.

Nico_the_other's avatar
Nico_the_other
Icon for Altocumulus rankAltocumulus
Dec 21, 2023

Hello. thank you Lucas_Thompson
I confirm that remote application is the OAUTH Client Application, the Authorization Server, the APM and the Ressource Server, the Virtual Server.
How do I know what is my current OAUTH implementation ? (I have nothing configured into Access/Federation/JSON web Token)

  • Lucas_Thompson's avatar
    Lucas_Thompson
    Icon for Employee rankEmployee
    Jan 02, 2024

    If you don't have OAuth configuration objects set up, BIG-IP will not participate in the OAuth protocol.

    To know what kind of OAuth you need to set up, you'll need to understand what kind of OAuth flow your deployment requires. There are many videos and articles that explain security and practicality implications of each type.

    • Nico_the_other's avatar
      Nico_the_other
      Icon for Altocumulus rankAltocumulus
      Jan 08, 2024

      hello Lucas_Thompson ,

      Thank you for your answer 🙂

      I'm sorry if I wasn't clear enough, but OAUTH is already setup on the F5, and it is already working. My question was about transmit "the application id" to the backend

      I already successfuly grab the information with, and tried to add a header.

       

      when HTTP_RESPONSE {
  set appName [string trim [ACCESS::session data get "session.oauth.authz.client_app_name"] "/Common/"]
  set appClientID [ ACCESS::session data get "session.oauth.authz.client_id"]
}

when ACCESS_POLICY_AGENT_EVENT {
  if { ([info exists appClientID]) and ([string length ${appClientID}] > 0) } {
    HTTP::header insert "X-PARTNER-ID" ${appClientID}
}

       

       The idea is to transmit to backend the application id used to do usage billing

      • Lucas_Thompson's avatar
        Lucas_Thompson
        Icon for Employee rankEmployee
        Jan 08, 2024

        Thanks for the extra detail.

        I'd suppose that if your user session is authenticated with APM (the user is sending APM's MRHSession cookie so is associated with an APM session) and the app ID is recorded inside the session, and the user is accessing the backend through APM, all you'd have to do is grab this info and add a header during ACCES_ACL_ALLOWED. This event is fired during each network request from users, and can be used more or less like HTTP_REQUEST.

         

        when ACCESS_ACL_ALLOWED {
          set appid [ACCESS::session data get "session.oauth.authz.client_id"]
          HTTP::header replace "X-PARTNER-ID" $appid
          log "Inserted appid: $appid"
        }