Forum Discussion
F5 APM Single IdP for Multiple SP's (Redirect External VIP to Internal VS's)
Hey there F5 community,
I've been trying to wrap my head around this one to see if it is possible, and may be looking at this under the wrong light...
We are trying to setup an environment such as idp.domain.com (Externally Available) and be able to route to internal only VIP's/Virtual Servers from it and utilize the Access Policy that resides on whatever virtual server it is redirected to, and handle SAML 2.0 communication policy's from there.
We've created internal only VIP's and VS's for each separate SAML service policy and SP Connectors. We have successfully got them working independently when those VIPs were externally available. However we are looking to consolidate and have a single entry point for SP Initiated Connections, then redirect to the Virtual Server bound for each separate SP, and utilize the policy attached to the internal only VS's.
I've attempted a few different iRule's that I have seen listed on the board here with very similar requests, but no luck yet. I am unable to bypass the initial policy of idp.domain.com and redirect to the internal only VS.
Example: SP Initiated to
DNS Pointing app1.domain.com to same External VIP as idp.domain.com
app1.corp.domain.com name of Internal VS with Policy, Bound with SP Connector and has own APM Policy
when HTTP_REQUEST {
switch [string tolower [HTTP::host]] {
"app1.domain.com" { virtual app1.corp.domain.com }
"app2.domain.com" { virtual app2.corp.domain.com }
}
}
Since it is landing on the External Available VIP for VS idp.domain.com, it is trying to process that policy without redirecting to the true end point VS of app1.corp.domain.com
I'm not sure if idp.domain.com needs to have no policy constraints, or if something perhaps in the swap host syntax that doesn't like the
"app1.domain.com" { virtual app1.corp.domain.com }
Periods in the actual Virtual Server name or something of that sort. Most time I've seen any VS referenced, I noticed everyone seems to use underscores, of course this is after we've previously built out separately with actual names. So I'm not sure if that causes syntax issues.
By chance does anyone have any recommendations?
Thanks!
- Yann_Desmarest_Nacreous
Hello,
I suggest to define your IDP as internal VS also. Then, you configure a public VS targeting all others (SP and IDP) using your irule :
when HTTP_REQUEST { switch [string tolower [HTTP::host]] { "app1.domain.com*" { virtual app1.corp.domain.com } "app2.domain.com*" { virtual app2.corp.domain.com } "idp.domain.com*" { virtual idp.corp.domain.com } default { reject } } }
I suggest adding a wildcard at the end of the hostname because sometimnes you will have request targetint "app1.domain.com:443" for example.
You should also define a default behavior.
- David_T_254046NimbostratusHi Yann, Thanks for the reply, I tried this but no luck thus far. I tried both destinations and it seems to break at the iRule level. Once I removed the iRule, I was able to hit the IDP destination from both links, but it solely uses the IDP Access Profile (As expected with External DNS Pointed to same IP). With iRule in place, I can't even get to the general IDP webtop and resources. I think I'm missing something on the iRule at this point when trying to re-route to the internal VS. I'll keep throwing darts at it until I can get something to stick.
- Manuel_Cristob3Nimbostratus
hi David were you able to find an answer ( that you can share) for your issue? Much appreciated ..
Hello,
I suggest to define your IDP as internal VS also. Then, you configure a public VS targeting all others (SP and IDP) using your irule :
when HTTP_REQUEST { switch [string tolower [HTTP::host]] { "app1.domain.com*" { virtual app1.corp.domain.com } "app2.domain.com*" { virtual app2.corp.domain.com } "idp.domain.com*" { virtual idp.corp.domain.com } default { reject } } }
I suggest adding a wildcard at the end of the hostname because sometimnes you will have request targetint "app1.domain.com:443" for example.
You should also define a default behavior.
- David_T_254046NimbostratusHi Yann, Thanks for the reply, I tried this but no luck thus far. I tried both destinations and it seems to break at the iRule level. Once I removed the iRule, I was able to hit the IDP destination from both links, but it solely uses the IDP Access Profile (As expected with External DNS Pointed to same IP). With iRule in place, I can't even get to the general IDP webtop and resources. I think I'm missing something on the iRule at this point when trying to re-route to the internal VS. I'll keep throwing darts at it until I can get something to stick.
- Manuel_Cristob3Nimbostratus
hi David were you able to find an answer ( that you can share) for your issue? Much appreciated ..
Hi,
How would the iRule look like when having one singe VIP/FQDN for external IDP and multiple APM profiles with SAML SSO?
Does the iRule above work with HTTP::path instead?
Thx Thrillseeker
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com