Forum Discussion

Vinne73's avatar
Vinne73
Icon for Cirrus rankCirrus
Nov 10, 2015

APM - Multi-domain SSO - problem with trailing &

Hi,

 

Can somebody using APM with Multi domain SSO do me a favor and test something? I seem to be running into a problem when the Original URL that's requested ends with &

 

Normally:

 

  1. You ask for the content Virtual Server
  2. Redirect to Login VS with an URI like /F5Networks-SSO-Req?SSO_ORIG_URI=[encoded Original url]
  3. Get redirected to content VS with an URI like /F5Networks-SSO-Resp?SSO_ORIG_URI=...

Now, when my Original URL ends with &, I get the steps above twice! And also, the second time around, the Original URL is decoded when I get back in step 3. Resulting in a massive fail and

 

Nov 10 13:06:22 f5cmiprod err tmm[2212]: 01490514:3: 00000000: Access encountered error: ERR_ARG. File: ../modules/hudfilter/access/access.c, Function: access_multidomain_sso_decode_redirect_uri, Line: 11746 Nov 10 13:06:22 f5cmiprod err tmm[2212]: 01490514:3: 00000000: Access encountered error: ERR_ARG. File: ../modules/hudfilter/access/access.c, Function: access_check_uri_type, Line: 10565

 

So, can somebody try this? Just add an & to your URL at the end.

 

Tx Vincent

 

APM
application delivery
deployment
LTM
security

3 Replies

Sort By
  • Lucas_Thompson_'s avatar
    Lucas_Thompson_
    Historic F5 Account
    Nov 10, 2015

    You're likely encountering bug ID 428268, documented here:

    http://support.f5.com/kb/en-us/solutions/public/15000/400/sol15445.html

    If you like, you can submit a request to Support to get a build with the fix for it. This issue is not resolved in any release or hotfix yet. Note that the trailing ampersand probably isn't required by the web server (it's the CGI delimiter) so you could probably just get rid of it. You could work around it by using an irule like this on your virtual:

     workaround for F5 bug ID 428268
 if the URI has unusual format in CGI parameters (trailing ampersand), fix it up

when CLIENT_ACCEPTED {
  ACCESS::restrict_irule_events disable
}

when HTTP_REQUEST {
  if { [HTTP::uri] ends_with "&" } {
    log local0. "Redirecting user to get rid of ampersand"
    HTTP::respond 302 Location [string range [HTTP::uri] 0 "end-1"]
  }
}
    • Vinne73's avatar
      Vinne73
      Icon for Cirrus rankCirrus
      Nov 12, 2015
      Yes this seems to be my problem. The "Applies to" needs to be updated because I run on 11.6. I guess the problem is not fixed yet. About the problem: it should be none of the BigIP's business what the Original URL is, and if it's properly formatted or not but that's just my opinion ;)
    • Lucas_Thompson_'s avatar
      Lucas_Thompson_
      Historic F5 Account
      Nov 12, 2015
      It's an acknowledged defect and will be fixed shortly. The system must parse this URI value because it's transformed into two different forms of redirect URL, one for the end policy redirect and one for the 302 multidomain bounce-back cookie setting implementation. It's just that the parser isn't flexible enough to parse unparsable things where the values don't conform to the CGI specification in RFC 3875.