Forum Discussion
CirrusF5 looses the token for the first call
Do you have any similar issue? or any idea :
with the token that it has retrieved from the AD Entra ID endpoint. The first call to the backend always loses the token on the way via F5, so it does not reach the backend at all. The frontend then goes to an error page (no authorisation).
If you then start the same call again, i.e. reload the frontend, everything works as expected.
5 Replies
David_WannaAltostratus
Hi Ozzy, can you kindly share more details on how you fixed this issue with an irule? We're running into a similar issue where we authenticate to the APM (VPN portal) using Entra ID. Once inside the portal, upon clicking on the app resource/link (app uses Entra ID as well), we're prompted to login to Entra ID again (this time fully proxied behind APM). Any help you can offer is greatly appreciated!
OzzyHi David , yes sure , we deploy this irule to our vs. It works fine. But first you should check authentication header
when HTTP_REQUEST {
set auth 0
if { [HTTP::header exists "Authorization"] } {
set auth [HTTP::header value "Authorization"]
}}
when HTTP_REQUEST_RELEASE {
if { !([HTTP::header exists "Authorization"]) && !($auth equals 0) } {
HTTP::header insert Authorization $auth
}unset auth
}
- Ozzy
Hello Jmtaylor,
First of all, thank you very much for answering and happy new year. We tried the steps you mentioned. We did not make any progress with these. We saw that the AUTH parameter was not transmitted to APM in the dumps I opened. Therefore, using an irule, we assigned the incoming auth parameter value to a variable and sent it with this variable. It worked this way.- Jmtaylor
Moderator
Happy New year to you as well. Thank you for sharing what worked to resolve this issue. I'm glad you were able to get it working as desired.
- Jmtaylor
Ozzy Have you been able to find a solution for this yet?
I was able to use some AI to assist with some options for you. Let us know if any of this is useful for you.this can be a tricky issue, but there are a few things you might want to check or try:
1. **Token Expiry and Synchronization**: Ensure that the token you retrieve from AD Entra ID is valid and not expired. Sometimes, there could be a time synchronization issue between your systems that causes the token to be invalid on the first call.
2. **Session Persistence**: Check the session persistence (or sticky sessions) configuration on your F5 load balancer. If the session is not sticky, the token might be lost or not properly forwarded to the backend on the first call.
3. **F5 Configuration**: Review your F5 configuration to ensure that the headers, including the authorization token, are being preserved and passed correctly. Sometimes, custom configurations or policies can strip out headers.
4. **Network Latency or Caching**: There could be network latency or caching issues that affect the first call. Investigate if any caching mechanisms are in place that might interfere with the token being sent on the first call.
5. **Logging and Monitoring**: Enable detailed logging on your F5 and backend to capture what happens to the token on the first call. This might give you insights into where the token is being lost.
6. **Retry Mechanism**: Implement a retry mechanism in your frontend to handle the first call failure gracefully, though this is more of a workaround than a solution.
If none of these suggestions resolve the issue, you might need to involve your F5 support or network team to dig deeper into the load balancer's behavior and configuration.
