Forum Discussion

Ustrum's avatar
Ustrum
Icon for Cirrus rankCirrus
Jul 08, 2022

Validating 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,...
application delivery
devops
  • Ustrum's avatar
    Ustrum
    Jul 08, 2022

    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's avatar
Nikoolayy1
Icon for MVP rankMVP
Nov 08, 2022

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