19-Sep-2023 14:25 - edited 19-Sep-2023 14:30
So say we have a redirect/rewrite in place which performs a redirect for
https://myapp.site.com/ (in VM host)
to
https://myapp.site.com/ (in kubernetes container host)
The new location is also available as: https://myapp.apps.site.com/
The effort is basically a replatforming mission--preserving path and querystring.
We wish to continue use of AD FS, however, it appears that AD FS is smart enough to detect that the underlying host is not the same and recognizes that a request for the AssertionConsumerService url is https://myapp.apps.site.com/
The user sees only https://myapp.site.com/
I know it's possible, but how do I get AD FS and F5 to play seamlessly together?
19-Sep-2023 19:24
Interesting issue. I would put in a support case with Microsoft, and find out how we can 'trick' it or rather 'make it work'. At that point, we can figure out how to perform trickery in terms of a) redirection, b) rewriting, c) header manipulation, d) cookie modifaction, e) different cert selection, etc. or anything else that is needed. I usually approach such a problem as 'what do we need to do to make it work'. Then I decide if it is possible to hack it with the F5 and the tools at my disposal, or do I fling my hands in the air and tell the application team 'unsupported, you figure it out'.
In your case, we need to understand what ADFS is unhappy about.
22-Sep-2023 06:39
Thanks @whisperer, so it's basically fixing what any federated identity provider would perceive as a "man-in-the-middle" attack. However, in this case, it is "an approved" [known] and intended workflow.
So, when we go from https://myapp.site.com/login to F5 to https://identityProvider.site.com/ (only knows myapp.apps.site.com at this point) to https://myapp.site.com the token no longer matches because myapp.apps.site.com was the referrer.
Hopefully that clarifies the problem domain a bit more.
20-Sep-2023 02:00
Hi @kirkpabk ,
Can you please try checking this old Devcentral post if it is related to your issue or not:
Original URL redirect after APM authentification - DevCentral (f5.com)
22-Sep-2023 07:01
I believe the article noted in the post,
Using APM as a SAML IdP no SSO portal (f5.com)
might help a bunch. But I need to look into it. It gets at the main requirement. So, these concepts are considered fairly advanced for the F5 team we have. I'm not sure how to present the solution the best way to get the needs met.
So, as state above, we from https://myapp.site.com/login to F5 to https://identityProvider.site.com/ (only knows myapp.apps.site.com at this point) to https://myapp.site.com the token no longer matches because myapp.apps.site.com was the referrer. Is the APM a separately licensed component or a common component with a basic F5 load balancing setup?