I´m trying to configure a per-request policy within an api protection profile so I can validate JWT tokens before allowing the request.
The first time a request comes in it works like charm, but it also creates a subsession with a lifetime set by the values in the soubroutine where the oauth scope is done and, for the lifetime of this subsession, subsequent requests will be catched in the same subsession and processed according to the first evaluation of the policy, which means that if the JWT has changed (gone from valid to invalid or the other way around) or it is not there anymore at all, it will not matter and the result will be the same as that in the first request evaluation.
I´ve tried to change the lifetime of the session but the smallest value is 60 sec, and also tried to catch the session id in an irule and completely remove the session (ACCESS::session remove -sid $apm_session_id), and even to change some of the session data (ip address) witht the hope that the next request wouldn´t match the same session, but that is simply not working even though syntactically the irule is correct.
Is there a way to force every request to be evaluated against the per-request policy independently instead of going through the same sub-session?
Thanks for the suggestion about gating criteria, I was finally able to work it around by:
Triggering an iRule event on every request before the oauth scope subroutine
Assigning perflow.custom a random value within the ACCESS_PER_REQUEST_AGENT_EVENT event
Seting the gating criteria to perflow.custom
Needless to say, this is far too twisted for my taste, specially when the docs mention it should work by simply setting the subroutine Max Subsession Life to 0, which I am unable to set to 0 even by patching the object directly calling the iControl API I get a similar error as in the gui ("01070734:3: Configuration error: The max subsession life timeout must range from 60 to 604800 seconds.") so it might be an internal validation.
To provide further info, the docs say that the Max Subsession Life should be set to 0 for the subroutine to be revalidated on every request, but the GUI doesn´t let me set it to 0:
Stange the the Max Subsession life is 0 and it writen:
Specify the
Max Subsession Lifein seconds.
This is the number of seconds after the session is validated when the session is considered expired, and the subroutine must be revalidated if a request occurs. The default is 900 seconds (15 minutes). If this is set to 0, the subroutine must be revalidated on every request.
Thanks for the suggestion about gating criteria, I was finally able to work it around by:
Triggering an iRule event on every request before the oauth scope subroutine
Assigning perflow.custom a random value within the ACCESS_PER_REQUEST_AGENT_EVENT event
Seting the gating criteria to perflow.custom
Needless to say, this is far too twisted for my taste, specially when the docs mention it should work by simply setting the subroutine Max Subsession Life to 0, which I am unable to set to 0 even by patching the object directly calling the iControl API I get a similar error as in the gui ("01070734:3: Configuration error: The max subsession life timeout must range from 60 to 604800 seconds.") so it might be an internal validation.
The error is saying timeout for some reason and the articles show that 0 should be possible so for me it seem as a bug that could be solved with newer versions but you made a nice workaround.
After quite a long time waiting I got a response from support, and it was quite dissapointing, saying that the doc has to be "interpreted":
The document states that "If this is set to 0, the subroutine must be revalidated on every request.". And we should read that statement that way: "if this could be set to 0, the subroutine would need to be revalidated on every request".
Then mentioning a couple of internal docs I don´t have access to, and stating it might be possible to set the Max Subsession Lifetime to 0 once an RFE is implemented, and suggesting I could purchase professional services to find a workaround for me (not needed since I already got one).
Good idea about the variable assign agent, saves me from the trigger and irule code, it does work indeed, thanks for that!
As I recenly had issues with API protection and Oauth In general with Azure AD I found the following article https://support.f5.com/csp/article/K11764434 and I am adding it if someone else sees your post and the solution you managed to find as the article "K11764434: Configure BIG-IP APM API protection session variables for secure API authorization" explains some interesting stuff 🙂
Edit:
I forgot to add that as mentioned in the article "By default, the Subroutine: OAuth Scope Check AuthZ gating criteria is set to expr { [ mcget {request.header.authorization} ] }. This means that the subroutine runs only when a request submits a different JWT. To enhance security, configure the gating criteria to take the API request URL into account as well so that the subroutine runs as long as there are any changes in the JWT and URL. ", so if the URL stays the same, I do not see a point in checking the same token and over again as when it changes then F5 APM or the backend apps may use something from the token's claims to see if the users is authorized for the new URL orn not.
