Forum Discussion

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

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 application id (from  "Access ›› Federation : OAuth Authorization Server : Client Application " ) to backend server.
Here is what I had understood about how it works (currently functionnal):

External form, when "Authentication button" is clicked, redirect to a form hosted and managed with APM on our F5.

An Access policy is used and when user is authenticated, the brower redirect to the external application using one of the defined url for the current Application ("Access ›› Federation : OAuth Authorization Server : Client Application "  : Security settings/Redirect URL(s) ).
Then, the next requests are authenticated.

I'd like to know if it is possible (and how) add an information that could be transmitted to backend server to identify the used application.

Little precision : we can't change the current behavior of the external app : it means that the solution should be on the BigIP.

Thank you for your help

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"
    }

     

10 Replies

Sort By
    • Lucas_Thompson's avatar
      Lucas_Thompson
      Icon for Employee rankEmployee
      Dec 13, 2023

      To add to this a little,

      I think you'd need to hard-code the app-id and just put it into the iRule manually. The data-plane in APM has some limited read access to *some* APM resource information (this is the info stored inside the "policy snapshot") using "ACCESS::session data get config <fully-qualified config object name>", but I'm almost certain that APM doesn't store information about app-ids in the snapshot.

  • Nico_the_other's avatar
    Nico_the_other
    Icon for Altocumulus rankAltocumulus
    Dec 14, 2023

    hello,
    Thank you Lucas_Thompson and zamroni777 for your answer, but i'm not sure that my explanations/expectations where clear.
    Here is a little scheme that reproduce what i try to achieve.

    • Lucas_Thompson's avatar
      Lucas_Thompson
      Icon for Employee rankEmployee
      Dec 14, 2023

      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)

  • Nico_the_other's avatar
    Nico_the_other
    Icon for Altocumulus rankAltocumulus
    Jan 09, 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