Forum Discussion

David_123856's avatar
David_123856
Icon for Nimbostratus rankNimbostratus
Jul 21, 2014

Is there a way to manipulate SAMLRequest in an iRule

I have an issue with an SP initiated SAML service where they have multiple Instances, but only provide one Issuer from all of them. In the Redirect request I can determine which instance from the RelayState param, but because the SAMLRequest has the same issuer it only ever matches my first configured SAML idp config.

 

I was considering deflating the SAML token in an iRule and then changing the issuer based on the relaystate, but can't figure out how to deflate the SAMLRequest URL param.

 

Anyone know if this is possible?

 

PS. Already asked about using HTTP Post from the SP and they dont support it. Has to be HTTP Redirect with the Request in the querystring

 

application delivery
BIG-IP Access Policy Manager (APM)
devops
iRules
security

8 Replies

Sort By
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Jul 21, 2014

    Sadly, I don't believe deflation/inflation are supported processes in iRules. You can definitely crack open a base64-encoded SAML POST request and muck with its values, but there's no way (in iRules) to deal with a deflated SAML Request message. I suppose, technically, it might be possible to create a pair of "service" VIPs and iRules to inflate the request, allow you to alter it, and then deflate it again, but this wouldn't be the most trivial thing to accomplish.

     

  • Michael_Koyfman's avatar
    Michael_Koyfman
    Icon for Cirrocumulus rankCirrocumulus
    Jul 21, 2014

    What exactly is your situation? Your SP has different instances and you need to service them by different IDP configs on your APM?

     

    • David_123856's avatar
      David_123856
      Icon for Nimbostratus rankNimbostratus
      Jul 21, 2014
      In point form caus its easier to type :): * The SP provides multiple instances - eg Test, Dev, QA, etc, * Each Instance at the SP has its own AssertionConsumerURL (eg. https://ACU/saml?Instance=QA * SP initiated SAML requests has the same SP Issuer inside the encoded token, but a different relaystate so I can tell from that url param which instance its for So I had set up 1 External SP config for each instance, and 1 idp Config for each instance, but as all the requests have the same SP Issuer the F5 matches the first idp service and then returns to that ones bound SP config. Have to use SO initiated due t links sent by the Service with no capacity to change the urls Unless I can bind multiple SPs to one idp and it can work out via the relay state which SP to use?
  • Michael_Koyfma1's avatar
    Michael_Koyfma1
    Icon for Cirrus rankCirrus
    Jul 21, 2014

    What exactly is your situation? Your SP has different instances and you need to service them by different IDP configs on your APM?

     

    • David_123856's avatar
      David_123856
      Icon for Nimbostratus rankNimbostratus
      Jul 21, 2014
      In point form caus its easier to type :): * The SP provides multiple instances - eg Test, Dev, QA, etc, * Each Instance at the SP has its own AssertionConsumerURL (eg. https://ACU/saml?Instance=QA * SP initiated SAML requests has the same SP Issuer inside the encoded token, but a different relaystate so I can tell from that url param which instance its for So I had set up 1 External SP config for each instance, and 1 idp Config for each instance, but as all the requests have the same SP Issuer the F5 matches the first idp service and then returns to that ones bound SP config. Have to use SO initiated due t links sent by the Service with no capacity to change the urls Unless I can bind multiple SPs to one idp and it can work out via the relay state which SP to use?
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Jul 21, 2014

    Just throwing this out there as I've dealt with something similar recently. Any chance that your environments are differentiated by hostname (ie. dev.domain.com, qa.domain.com, test.domain.com)? If so, you could:

    1. Create separate SP configs, access policies, and "internal" VIPs for each.

    2. Bind all of the SP configs to the IdP.

    3. Create an external LTM that fronts the internal APM VIPs and an iRule that load balances to the APM VIPs based on hostname (or any other consistent value in the request):

      when HTTP_REQUEST {        
    switch [string tolower [HTTP::host]] {            
        "dev.domain.com" { virtual dev_apm_vs }
        "qa.domain.com" { virtual qa_apm_vs }                
        "test.domain.com" { virtual test_apm_vs }
    }
}

    Now that I'm thinking about it, and I don't have it in front of me to test, but isn't the relaystate value a query string value outside the encoded SAML request? You could use a similar "layered" VIP approach to alter the relaystate.

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Jul 22, 2014

    You would need separate SP configurations with their own entity URL, and then bind all of those to the single IdP. The APM IdP should then redirect to the respective Assertion Consumer Service URLs individually.

     

  • Algebraic_Mirror's avatar
    Algebraic_Mirror
    Icon for Cirrostratus rankCirrostratus
    Aug 02, 2015

    Did you ever solve this? It turns out Office365 has this same problem: if you have multiple domains inside a single tenant account, they all come in with the Issuer ID and the same Assertion Consumer Service URL. The way to distinguish them (and the way ADFS handles this) is to look at the user that the SP sent the assertion request for. The user comes in in a name@domain.com format, and the domains will be different there, which is how ADFS tells the SPs apart.

     

    I'd like to do the same thing on the F5. I'm sure there's probably a way to do decodes and look at the SAML request, but is there any way to override what IDP configuration gets selected based on what I find the user name to be? Unfortunately, Microsoft requires that if you have two domains, the IDP sends back assertions to each domain with a different issuer ID so that Microsoft can tell them apart. (I wish they would do the same for us when their SPs send their assertion requests!)