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

Gabriel_V_13146's avatar
Mar 26, 2014

SAML IdP fails to validate the redirect signature

Hello all,

 

I don't know how to split it, but there are two intertwined issues.. Using F5 APM as IdP (Internal BIGIP-11.4.1-plus-hf2.14-build2) it should support POST and Redirect binding for the Single Login Service (single log in).

 

  1. Using the Redirect binding, the signature is in the URI (not in the message itself, this is according the binding specification 3.4.4.1) "GET /saml/idp/profile/redirectorpost/sso?SAMLRequest=....&RelayState=...&SigAlg=...&Signature=..." and APM fails to validate the SAMLRequest (warning tmm[7975]: 014d0002:4: c5c485f7: SSOv2 Authn Request has no Signature element). A nice workaround was to use POST binding, when the request signature is in the message itself. Then it works. For a single domain Access Policy.

     

  2. Using a multi domain access policy, the user is redirected to the default authentication URI with encoded original (target) URI. In case of the POST request, the posted data are lost (? or not submitted). That brings us to the first part - using the redirect binding and failing to validate the message signature.

     

So far the login request can be unsigned and we could require to sign only SLO (with another issues), however this has to be configured directly using tmsh..

 

I couldn't find if there is a support ticket for this. So - so far we cannot validate the login request from the redirect binding. Anybody an idea for a workaround?

 

Gabriel

 

2 Replies

  • I'd like to address some of these concerns.

     

    1. I didn't believe until I saw it for myself, but you appear to be correct concerning the SigAlg and Signature parameters in the SAMLRequest HTTP-Request binding. An APM SP (perhaps incorrectly), when configured to sign authentication requests will embed the signature and signature algorithm in the encoded SAMLRequest. I would recommend opening a case to address this.

       

    2. A multi-domain access policy is not in any way related to SAML, though they have similar characteristics. As to your findings you are again correct. The redirect from the logon URI produces a GET request, and would lose any initial POST to the application URI. There are conceivably ways around this though.

       

  • I believe I've stumbled into this configuration. Multi-domain APM policy acting as IDP, with a single domain APM policy acting as SP.

     

    Any word back from support regarding this?