Forum Discussion
Nico_the_other
Altocumulus
AltocumulusBIGIP 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...
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"
}
Nico_the_otherAltocumulus
Altocumulushello,
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
Employee
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:
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
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
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.