ArcGIS Enterprise 11.1 OAuth regression ?!

1813
10
Jump to solution
05-02-2023 07:49 AM
NicolasGIS
Occasional Contributor III

Hello,

Since we upgraded our ArcGIS Enterprise from 11.0 to 11.1, applications using OAuth can no longer authenticate.

Indeed, response redirection (https://myapp.company.com?code=foo&state={bar}) is rejected by our webserver with the following error:

HTTP 400: Invalid character found in the request target: The valid characters are defined in RFC 7230 and RFC 3986.

Description: The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

Reports are coming mainly from users using Apache Tomcat web server and NGINX.

Seems like curly braces are no longer encoded ?! 

Thanks,

Nicolas

1 Solution

Accepted Solutions
JeffSmith
Esri Contributor

@NicolasGIS- Yes, I have been able to reproduce that issue and it appears to be unique to the IIS web adaptor in 11.1.  If Enterprise is configured with the Java web adaptor, the curly braces are encoded.  That might be a possible workaround for you.  We will work to get that fixed in the IIS web adaptor.  If you want to track the status of it, please contact Support and have a bug logged.

View solution in original post

0 Kudos
10 Replies
JeffSmith
Esri Contributor

@NicolasGIS- Yes, I have been able to reproduce that issue and it appears to be unique to the IIS web adaptor in 11.1.  If Enterprise is configured with the Java web adaptor, the curly braces are encoded.  That might be a possible workaround for you.  We will work to get that fixed in the IIS web adaptor.  If you want to track the status of it, please contact Support and have a bug logged.

0 Kudos
JeffSmith
Esri Contributor

I wanted to follow-up to my solution for this issue to clarify a few things.  The way the bug was logged makes it sound like Portal logins are blocked for anyone using the IIS web adaptor.  That is not the case.  While the underlying issue with the unencoded curly brackets exists for anyone with the IIS web adaptor in 11.1, the OAuth login issue will only be encountered for organizations that use a front-end load balancer or reverse proxy that does not accept the curly brackets in the query parameters.  Logins directly through the IIS web adaptor will work fine since IIS accepts unencoded curly brackets.

Similarly, as @NicolasGIS pointed out, if the OAuth login redirects to a 3rd-party application running on a web server that blocks the curly brackets, the login issue will be observed there as well.

0 Kudos
NicolasGIS
Occasional Contributor III

Thanks @JeffSmith for the quick reply and for identifying that ArcGIS WebAdaptor for IIS was the culprit !

The following BUG has been logged:

[BUG-000158033]  - Logging to Portal fails with HTTP 400 Error, because the ArcGIS Web Adaptor forwards the redirect URL with not encoded curly braces

DavidColey
Frequent Contributor

Hi all - @JeffSmith , I don't see how anyone in a Windows shop can just switch over the java edition web adaptor, so what does this mean in practical terms? 

Does this mean that developer edition apps like EM and or the WAB that are registered with Portal at 11.1 cannot login?

Or does this mean that Portal-hosted WABs, EBs and Instant Apps, if not shared with 'Everyone' cannot be accessed?

I have the upgrade scheduled for this weekend and am trying to run down any of the gotchas that have appeared in GeoNet thus far

Tags (1)
JeffSmith
Esri Contributor

@DavidColey Yes, I agree.  Switching to a Java web adaptor even temporarily might be difficult for some organizations.  I'm hoping we can get this fixed and patched soon. 

Keep in mind this issue will only impact organizations that use a front-end load balancer or reverse proxy that does not accept the curly braces in the query parameters.  By default IIS will allow unencoded curly braces included in the query parameters so I don't think most Windows shops will encounter this.

0 Kudos
DavidColey
Frequent Contributor

Ok thanks for the update @JeffSmith - yes, we could not just switch to the Java version of the WA.  That being said, we use f5 for our front end traffic cop - it does no load balancing for us.  Still, I do not think that, by default this is an issue for f5 front ends.

0 Kudos
NicolasGIS
Occasional Contributor III

Or, in my case, any third party applications (API users that have oauth application registered on Portal for ArcGIS) and that are not on IIS web servers. I think it could have worked if they had use Oauth2 implicit flow though (not recommanded).

Personally, I fixed it at reverse proxy level.

Bobba
by
New Contributor

Hello All,

I am also facing a similar issue. Since we upgraded our ArcGIS Enterprise from 10.9 to 11.1, application using OAuth can no longer authenticate.

The issue is that my app is configured to use the 'axsRTsjGjdT' appId for Esri's OAuth for authorization. When the authentication is initiated from dev.mydomain.com endpoint, the appId changes to 'arcgisonline'. It works well when the authentication is initiated from the AppService Endpoint or the Test Endpoint.

App Service Endpoint: myapp.azurewebsites.net
Dev Domain: https://dev.mydomain.com/myapp/
Test Domain: https://test.mydomain.com/myapp/

Portal for ArcGIS: https://dev.mydomain.com/portal/

Note: Both endpoints are pointing to the same app service are configured to use same Portal for troubleshooting.


Technology stack:

Application - Built in ReactJS and hosted on Azure App Service (App Service plan/PremiumV2 (P2v2)).

Portal for ArcGIS: Enterprise 11.1

The listers, backend settings, pools, rules, and rewrites are configured in the Application Gateway to allow access to this AppService & Portal for ArcGIS.

 

Thanks,
Bobba

JTessier
Occasional Contributor II

@Bobba , we are in a similar boat, did you find a solution? 

0 Kudos