Forum Discussion

David_T_254046's avatar
David_T_254046
Icon for Nimbostratus rankNimbostratus
Mar 21, 2016

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!

application delivery
BIG-IP Access Policy Manager (APM)
devops
idp
iRules
LTM
saml
  • Yann_Desmarest_'s avatar
    Yann_Desmarest_
    Icon for Nacreous rankNacreous
    Mar 21, 2016

    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_254046's avatar
      David_T_254046
      Icon for Nimbostratus rankNimbostratus
      Mar 21, 2016
      Hi 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_Cristob3's avatar
      Manuel_Cristob3
      Icon for Nimbostratus rankNimbostratus
      Jul 14, 2017

      hi David were you able to find an answer ( that you can share) for your issue? Much appreciated ..

       

  • Yann_Desmarest's avatar
    Yann_Desmarest
    Icon for Cirrus rankCirrus
    Mar 21, 2016

    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_254046's avatar
      David_T_254046
      Icon for Nimbostratus rankNimbostratus
      Mar 21, 2016
      Hi 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_Cristob3's avatar
      Manuel_Cristob3
      Icon for Nimbostratus rankNimbostratus
      Jul 14, 2017

      hi David were you able to find an answer ( that you can share) for your issue? Much appreciated ..

       

  • Thrillseeker_12's avatar
    Thrillseeker_12
    Icon for Cirrus rankCirrus
    Apr 13, 2017

    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