Redirect/Rewrite to Same Host URL different Host with App AD FS Authentication

[kirkpabk]

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?

[whisperer]

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.

[kirkpabk]

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.

[F5_Design_Engineer]

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)

[kirkpabk]

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?