Forum Discussion
Ustrum
Cirrus
CirrusValidating JWT in per-request policy - subsession
Hello,
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?
TIA,
Pablo
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.
- Nikoolayy1
MVP
Stange the the Max Subsession life is 0 and it writen:
-
Specify theMax 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.https://techdocs.f5.com/en-us/bigip-15-1-0/big-ip-access-policy-manager-per-request-policies/implementing-device-posture-checks/configuring-subroutine-settings.htmlhttps://techdocs.f5.com/en-us/bigip-15-1-0/big-ip-access-policy-manager-per-request-policies/using-step-up-authentication/overview-configuring-policies-for-step-up-authentication/specifying-how-often-a-user-must-step-up.htmlThis if I read it correcly should do what you want.Outside of this being a bug maybe also see your perflow gating criteria:
- Ustrum
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.
-
- Nikoolayy1
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.
I forgot to add
