For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Eric_Raff_11012's avatar
Eric_Raff_11012
Icon for Nimbostratus rankNimbostratus
Jul 22, 2014

APM as SAML SP and multiple host names

I have an existing LTM VIP that has multiple host names pointing to it. I would like to setup SAML authentication (as a service provider to an external IdP) on this VIP with an APM policy. I have that working great for one host name by creating the local SP Service with an Entity ID of that one host. The problem is trying to make this work on any of the possible host names that resolve to this VIP. I am hoping that relay state could be used here but not sure how to set the value of the relay state to the initial requested uri. Possibly using the session.network.name session variable to do that? I have seen redirect loops in playing with the relay state paramater as well as SAML errors in APM so not sure that will end up working anyway. I understand that I could setup an "internal" VIP for each host name and then setup a separate SAML SP to represent each host name and add an iRule to the LTM VIP that detects the host name and routes to the proper virtual server but I am dealing with at least 6 host names all using this one VIP and this adds a fair amount of administrative over head that I would rather not have to setup and manage. Any creative ideas of how to support multiple host names through one SAML SP for client side authN? Thanks for your help in advance.

 

7 Replies

  • I have the exact same problem as you. Did you manage to make this work ? I can't seem to find anything regarding this anywhere :( As a comparison, Shibboleth SP sets the AssertionConsumerServiceURL of the Auhthn request to the requested hostname.
  • I spent some additional time looking at options, and came to discover one important (and admittedly annoying) nuance of the APM IdP: it matches on both the AssertionConsumerServiceURL and EntityID values of the bound SP config. I wrote a layered LTM VIP iRule to try to change either on the way out (to adjust for the actual host name), but got the same error in both cases:

    SSOv2 Error: No SP Connector attached to SAML SSO (/Common/idp.domain.com) matching authentication request. If ACS URL is present in authentication request it should match ACS URL from SP Connector. If Issuer is present in authentication request it should match entity_id from SP Connector.
    

    So because the ACS and EntityID values are bound to the SP config, which is bound to the IdP, you cannot dynamically change them in flight. I know it seems taxing, but doing the layered approach with one LTM external VIP and 6 internal APM VIPs (with individual SP configs all bound to the single IdP) may be the least complicated way to make this work.

  • What Merill proposed works.

     

    If you have different certificates for different sites, but on the same VIP, the following feature works together with different SAML SP per site binding to the same IdP.

     

    K13452: Configuring a virtual server to serve multiple HTTPS sites using the TLS Server Name Indication feature https://support.f5.com/csp/article/K13452

     

  • I have a slight variation, on this problem. I need to support SAML Auth (external IdP) and local auth with the built-in logon page. Any ideas on how to configure the VPE?

     

  • R u doing one site for SAML SP auth, another site for local auth with built in logon page?

     

    Or you have one site doing SAML SP first, and fall back to local auth?

     

    • Walter_Kacynski's avatar
      Walter_Kacynski
      Icon for Cirrostratus rankCirrostratus

      It's 1 VIP and 1 Policy. I need to default to the logon page unless a special URL is invoked for SP Initiated or support IdP initiated.

       

    • sding_254965's avatar
      sding_254965
      Icon for Nimbostratus rankNimbostratus

      Just have a macro, you can check the URL with general purpose empty, then construct your own branch, if expr { [mcget {session.server.network.name}] == "saml.foo.bar" }, then continue to a SAML Authentication. fallback, continue to an logon page, then local authentication.