Forum Discussion

Gabriel_V_13146's avatar
Jul 23, 2014

Is SAML 2.0 ForceAuthn respected?

Dear sirs,

 

I've got few questions about SAML re-authentication. When using BIGIP APM as an SAML IdP - is the ForceAuthn attribute in the Authentication Request respected? Is the user re-authenticated? If not - can we handle the event in an iRule (close a session to force the authentication) or a response is sent immediately?

 

Thank everybody for any enlightment

 

Gabriel

 

1 Reply

  • Every indication that I have from testing shows that ForceAuthn is indeed ignored at the APM IdP. I had to noodle on this one for awhile and came up with the following, admittedly hokey solution:

    when HTTP_REQUEST {
        if { [HTTP::uri] starts_with "/saml/idp/profile/redirectorpost/sso" } {
            if { ( [HTTP::cookie exists MRHSession] ) and ( [HTTP::header Referer] contains "/my.policy" ) } {
                return
            } else {
                HTTP::cookie remove MRHSession
            }
        }   
    }
    

    This is an iRule you apply to the IdP VIP. It essentially does this:

    If the request is for "/saml/idp/profile/redirectorpost/sso" and the MRHSession cookie exists in the request and the Referer header contains "/my.policy", do nothing. When APM IdP is processing, it will redirect to itself one time with this URL, and the cookie and Referer header will be set, so we want to ignore this request. When the second SP makes its request, the MRHSession cookie from the first SP auth will be in that request (but not the Referer), so we're going to remove the MRHSession cookie from the ingress flow to APM, causing APM to start a new session and send a new MRHSession cookie to the browser (overwriting the first one). The old session will simply time out.

    The above should cause APM IdP to start a new logon session for each new SP. It does not, unfortunately, do so based on the ForceAuthn value. If the SAMLRequest was POST-bound (in the payload of a POST request), you could technically crack it open in the IdP's HTTP_REQUEST event and read it there before removing the MRHSession cookie. But if the SAMLRequest is Redirect-bound (in the URI of a redirect), iRules don't currently have a way to gzip inflate this encoded content.