[OPENAM-9597] Goto URL with multiple query string parameters incorrectly decoded Created: 22/Aug/16  Updated: 22/Jul/20  Resolved: 27/Sep/16

Status: Resolved
Project: OpenAM
Component/s: XUI
Affects Version/s: 13.5.0, 14.0.0
Fix Version/s: 13.5.1, 14.0.0

Type: Bug Priority: Major
Reporter: Jake Feasel Assignee: Julian Kigwana [X] (Inactive)
Resolution: Fixed Votes: 1
Labels: AME, Must-Fix, OAuth2, TURING
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on OPENAM-9619 URL Parameters are ignored during login Resolved
is required by OPENAM-9626 Broken FacebookSocialAuthenticationSe... Resolved
is required by OPENAM-9719 session upgrade fails in combination ... Resolved
Duplicate
is duplicated by OPENAM-9630 Oauth2 authorise endpoint not encodin... Resolved
is duplicated by OPENAM-9662 XUI does not correctly set link to re... Resolved
is duplicated by OPENAM-9664 "Return to Login Page" link after log... Closed
Regression
caused OPENAM-10752 Social Authentication in a subrealm w... Open
Relates
relates to OPENAM-9664 "Return to Login Page" link after log... Closed
is related to OPENAM-5547 Agent behaviour when appending goto= ... Closed
is related to OPENAM-9664 "Return to Login Page" link after log... Closed
Target Version/s:
Sprint: Sprint "Anise" 113 - Turing, Sprint "Baharat" 114 - Turing
Support Ticket IDs:
QA Assignee: Filip Kubáň [X] (Inactive)
Verified Version/s:

 Description   

OpenAM needs to be able to redirect an unauthenticated user to a specific URL after they authenticate. This URL may contain multiple query string parameters, such as "http://www.google.com/?foo=bar&hello=world". This URL it is expected to be encoded and passed into the XUI as a URL like so:

/openam/XUI/#login/&goto=http%3A%2F%2Fwww.google.com%2F%3Ffoo%3Dbar%26hello%3Dworld

The REST endpoint "/openam/json/authenticate" also expects to receive this URL as an encoded parameter. This is used to start the authentication process, and the goto URL provided to the authentication process will be retained throughout the lifetime of the session that will be created.

The problem is that the encoded value passed into XUI is being decoded before it is passed to the authenticate endpoint. This is especially problematic when URLs contain multiple parameters, as it causes the URL-splitting logic to incorrectly parse the subsequent parameters of the goto URL as being additional parameters to the authenticate endpoint (unrelated to the goto URL). For example, the above would be passed in like so:

/openam/json/authenticate?goto=http://www.google.com/?foo=bar&hello=world

Thus, the value for the "goto" parameter would only be "http://www.google.com/?foo=bar", and there would be another (likely ignored) parameter "hello=world" treated separately.

The expected behavior is for the XUI to submit this goto URL encoded, like so:

/openam/json/authenticate?goto=http%3A%2F%2Fwww.google.com%2F%3Ffoo%3Dbar%26hello%3Dworld

This is especially troublesome for the OAuth flow. In that case, the "authorize" endpoint redirects unauthenticated users to the XUI login page, with a URL like so:

/openam/XUI/#login/&realm=%2F&goto=http%3A%2F%2Frich.example.com%3A8080%2Fopenam%2Foauth2%2Fauthorize%3Fresponse_type%3Dcode%26scope%3Dopenid%2520profile%2520email%26redirect_uri%3Dhttps%253A%252F%252Flocalhost%253A8443%252FoauthReturn.html%26state%3Dlogin%2526provider%253Dopenam%2526redirect_uri%253Dhttps%253A%252F%252Flocalhost%253A8443%252FoauthReturn.html%26client_id%3Dopenidm

However when the XUI loads, it submits the goto URL it was provided to the "authenticate" endpoint without retaining the encoding, so that the authenticate endpoint only sees a goto URL with a value like so:

http://rich.example.com:8080/openam/oauth2/authorize?response_type=code

The remaining, critically-important OAuth parameters are missing from the URL, so that when the authentication process completes the authorization endpoint is unable to process the request and the user can't return to their requested application (the RP) with the authorization code.



 Comments   
Comment by Julian Kigwana [X] (Inactive) [ 05/Sep/16 ]

The Steps to reproduce in this JIRA as incorrect so it is difficult to find a fix. My original PR solved the problem described, however I have since learnt that the urls provided are inaccurate.

Comment by Peter Major [X] (Inactive) [ 26/Sep/16 ]

The fix on 13.5.1 appears to break SAML authentication. The goto parameter's value is now URL encoded, and because of that the RestLoginView.js's goto checking for /SSORedirect now no longer works since the goto parameter's value now actually has %2FSSORedirect.
Either the goto parameter should be URL decoded or the code in RESTLoginView.js needs to be updated to fix the SAML flow in my opinion.

Comment by Filip Kubáň [X] (Inactive) [ 25/Nov/16 ]

Verified fix on: OpenAM 14.0.0-M6 Build 73f9e2bdde (2016-November-18 10:20)

Comment by venu alla [ 01/Mar/17 ]

this was tested in 13.5 (adding here for more bug metadata in case someone has the same problem).
Setup : OIDC client <to> (OP)OpenAM(SP) <via> saml2AuthModule <to>Remote-IDP
Results in "client_id" missing on /authorize endpoint, as the OIDC params are stripped by XUI
See logs
27.0.0.1 - - [28/Feb/2017:23:10:26 -0700] "POST /idp/json/authenticate?realm=/&realm=/&service=soneIdp&goto=http://my.idp.com:8080/idp/oauth2/authorize?service&response_type=code&scope=openid%20profile%20email&nonce=1234&login_hint=john@sone.com&client_id=oidcClient&redirect_uri=http://localhost:8080/springmvc/oidccallback&authIndexType=service&authIndexValue=sonyIdp&responsekey=73b9ae3f-162c-4fa6-9eeb-d35be502f208&error=false HTTP/1.1" 200 183
127.0.0.1 - - [28/Feb/2017:23:10:26 -0700] "POST /idp/json/users?_action=idFromSession&realm=/ HTTP/1.1" 200 547
127.0.0.1 - - [28/Feb/2017:23:10:26 -0700] "GET /idp/json/users/john@sone.com?realm=/ HTTP/1.1" 200 1307
127.0.0.1 - - [28/Feb/2017:23:10:26 -0700] "POST /idp/json/users?_action=validateGoto HTTP/1.1" 200 79
127.0.0.1 - - [28/Feb/2017:23:10:26 -0700] "GET /idp/oauth2/authorize?service HTTP/1.1" 400 1886

Comment by Alex Walker [X] (Inactive) [ 12/Apr/17 ]

verified fixed in the 201704 patch for 13.5.0

Generated at Fri Oct 23 10:40:10 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.