Issue in the Token Generation using a Reverse Proxy Server (Apache) with Portal

[lvargas]

Hello,

The environment is ArcGIS Enterprise 10.7.1 federated and distributed in 3 servers in Windows Server (Portal, ArcGIS GIS Server and DataStore), is running "normally" and are virtualized servers in VMware.

Tomcat and WebAdaptor were used to expose the environment, but due internal rules the organization it was decided not to use it and to expose it through a reverse proxy, Apache is used to manage the communication.

They have a rule like this.

RewriteEngine On

RewriteCond %{REQUEST_METHOD} ^TRACE

RewriteRule .* - [f]

RewriteCond %{REQUEST_METHOD} ^TRACK

RewriteRule .* - [f]

RewriteRule ^/portal$ https://public.dns.com/portal/

<Location “/portal”>

ProxyPass https://internal.server.domain:7443/arcgis

ProxyPassReverse https://internal.server.domain:7443/arcgis

Header set Access-Control-Allow-Origin “*”

</Location>

Almost the same conifguration for the ArcGIS GIS Server.

The access to Portal website is viable, you can log in, see the services (from ArcGIS GIS Server and hosted), view the viewers created before, creates new maps, WAB etc.

The issue its related to Portal, when it is required to access for example to Survey123 app, the ArcGIS Server manager to check the services etc (where it is required to generate security tokens) it returns the URL of the internal machine where the request was directed. This is problematic, as clients will not be able to access this URL. Also, this gives the client access to some information about the internal machine.

This is the same situation describe here.

Prepare your reverse proxy

https://enterprise.arcgis.com/en/web-adaptor/latest/install/iis/using-a-reverse-proxy-server-with-po...

The request starts from something like this (the correct url):

https://public.dns.com/portal/sharing/rest/oauth2/authorize?....

But it is redirected to the internal Portal server.

https://internal.server.domain:7443/portal/sharing/rest/oauth2/authorize?....

We can manually correct the url from internal.server.domain:7443 to public.dns.com and works fine, but this should be done by the reverse proxy.

We believe that its related to the value X-Forwarded-Host, that Apache do not have it; be we're not sure how configured, we have tried different configurations online and don’t work.

Have you seen this inconvenience before?

Regards.

[ChristopherPawlyszyn]

Hello @lvargas,

I did some testing on an HTTPD reverse proxy installed on a CentOS VM and did not see the effect you are describing, I've attached a sanitized snippet of my HTTPD ssl.conf file with the relevant information.

According to the Apache documentation (linked below) the X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Server headers are all appended by default to the request when using the ProxyPass directive.

mod_proxy - Apache HTTP Server Version 2.4
https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#x-headers

Have you confirmed the WebContextURL is configured for the Portal site?

RewriteEngine On
SSLProxyEngine On

<Location "/portal">
    ProxyPass https://machine.domain.com/portal/home
</Location>

<Location "/server">
    ProxyPass https://machine.domain.com/server/rest/services
</Location>

<Location "/portal/">
    RedirectMatch ^/portal/$ https://machine.domain.com/portal/home/
    ProxyPass https://machine.domain.com:7443/arcgis/
    ProxyPassReverse https://machine.domain.com:7443/arcgis/
</Location>

<Location "/server/">
    RedirectMatch ^/server/$ https://machine.domain.com/server/rest/services
    ProxyPass https://machine.domain.com:6443/arcgis/
    ProxyPassReverse https://machine.domain.com:6443/arcgis/
</Location>

[lvargas]

Hello @ChristopherPawlyszyn 

Thanks for your comments.

I made the changes, and now it is like this (for security reasons server name and the public dns have been changed). I have verified and the inconvenience persists.

<VirtualHost *:443>

ServerName ubuntu.dns.com
ServerAlias ubuntu.dns.com

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

SSLCertificateFile /etc/ssl/certs/apache.crt
SSLCertificateKeyFile /etc/ssl/private/apache.key


SSLEngine on
RewriteEngine On
SSLProxyEngine On

<Location "/portal">
ProxyPass https://ubuntu.dns.com/portal/home
</Location>

<Location "/server">
ProxyPass https://ubuntu.dns.com/server/rest/services
</Location>

<Location "/portal/">
RedirectMatch ^/portal/$ https://ubuntu.dns.com/portal/home/
ProxyPass https://internal.server.domain:7443/arcgis/
ProxyPassReverse https://internal.server.domain:7443/arcgis/
</Location>

<Location "/server/">
RedirectMatch ^/server/$ https://ubuntu.dns.com/server/rest/services/
ProxyPass https://internal.server.domain:6443/arcgis/
ProxyPassReverse https://internal.server.domain:6443/arcgis/
</Location>

</VirtualHost>

In Portal we can check the ArcGIS Server federation, and looks fine.

In the admin too.

In Portal the URL of ArcGIS Server looks fine (https://ubuntu.dns.com/server).

But if we select it, to take us to ArcGIS Manager; it continues addressing to the internal server.

https://internal.server.domain:7443/portal/sharing/oauth2/approve?oauth_state=mC7oBv_Zc_QIonWy4HsBUXyLIxJxXO9-gaBsz_M

The wrong in the redirection is the name of the internal server, which corresponds where the Portal is installed, the /portal/token etc its fine.

This happens when access token generation is necessary, for example when you login into Survey123.

It seems that there are some additional details that should be modified.

Regards.

[lvargas]

Hello @ChristopherPawlyszyn 

Have you confirmed the WebContextURL is configured for the Portal site?

Yes, both webcontexturls (Portal and ArcGIS GIS Server) are configured with the external DNS.

Portal

ArcGIS GIS Server

Regards.

[ChristopherPawlyszyn]

Hello @lvargas,

I think I understand the behavior now and have amended my /portal location configuration, let me know how it fares for you.

<Location "/portal/">
    ProxyPreserveHost On
    RedirectMatch ^/portal/$ https://machine.domain.com/portal/home/
    RedirectMatch ^/portal/portaladmin$ https://machine.domain.com/portal/portaladmin/
    ProxyPass https://machine.domain.com:7443/arcgis/
    ProxyPassReverse https://machine.domain.com:7443/arcgis/
</Location>

[lvargas]

Hello @ChristopherPawlyszyn 

Thanks for your comments and time.

Using ProxyPreserveHost On affects the redirection of the site, when we use https:// ubuntu.dns.com/portal/home/ a redirection is made to https://internal.server.domain/arcgis/home/ so its not possible use the site.

An option I have used is to disable the headers, ProxyAddHeaders Off

<Location "/portal/">

    ProxyAddHeaders Off

    RedirectMatch ^/portal/$ https://ubuntu.dns.com/portal/home/

    RedirectMatch ^/portal/portaladmin$ https://ubuntu.dns.com /portal/portaladmin/

    ProxyPass https://internal.server.domain:7443/arcgis/

    ProxyPassReverse https://internal.server.domain:7443/arcgis/

</Location>

The site cannot validate the ArcGIS Server because the application sets internally the URL as https://ubuntu.dns.com:7443/portal... Adding the portal's internal port (7443) to the correct DNS.

This also affects the creation of new elements, for example registering a new application in the App Launcher, since the token that internally generates corresponds to: https://ubuntu.dns.com:7443/portal/portaladmin?f=json&token=SOEj8v9ckAy1_Ye9uLOSGXIqxkAIvwwTq5SpAyph....

But something that its fine, its that even having this issues I can click on the federated server (Portal Settings Server), the redirection & tokens works fine, and I can check the manager.

Regards.

[ChristopherPawlyszyn]

Hello @lvargas,

I'm surprised since I am seeing no redirection to 7443 on any of the endpoints of my ArcGIS Enterprise deployment behind this proxy.

What if you try appending the correct X-Forwarded-Host header after the 'ProxyAddHeaders Off' statement according to our documented needs for Portal's WebContextURL?

Something like 'Header set X-Forwarded-Host dnsalias.domain.com' in the same section may work.

[lvargas]

Hello @ChristopherPawlyszyn 

Thanks for the recomendation, it seems that dont have effect.

I have added the parameter, and I restarted the service.

<Location "/portal/">
    ProxyAddHeaders Off
    Header set X-Forwarded-Host ubuntu.dns.com
...

Check, and intertally I can see that rewrites the port to 7443.

This happens in all the site, for example when the end user logged out.

Or in Portal when try to validate the federated server.

I have also tried enabling the proxyaddheaders on and adding the sert x-fordwarded-host header but it doesn't work either (redirects to https://internal.server.domain:7443/portal/...).

Im trying to doing a port redirection; but I have no luck

RewriteCond %{SERVER_PORT} 7443
RewriteRule ^(.*)$ https://ubuntu.dns.com/$1 [R,L]

Regards.

[lvargas · Accepted solution]

Hello,

I share this configuration, in case someone has the same problem.

<VirtualHost *:443>

ServerName public.dns.com
ServerAlias public.dns.com

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

SSLEngine on
SSLProxyEngine On

SSLCertificateFile      /etc/ssl/certs/wildcard.crt
SSLCertificateKeyFile /etc/ssl/private/wildcard.key

<Location "/portal">
    ProxyPass https://public.dns.com/portal/home
</Location>

<Location "/server">
    ProxyPass https://public.dns.com/server/rest/services
</Location>

<Location "/portal/">
    RedirectMatch ^/portal/$ https://public.dns.com/portal/home/
    ProxyPass https://internal.server.domain:7443/arcgis/
    ProxyPassReverse https://internal.server.domain:7443/arcgis/
    ProxyPassReverse https://internal.server.domain:7443/portal/
</Location>

<Location "/server/">
    RedirectMatch ^/server/$ https://public.dns.com/server/rest/services
    ProxyPass https://cinternal.server.domain:6443/arcgis/
    ProxyPassReverse https://internal.server.domain:6443/arcgis/
</Location>

</VirtualHost>

Its possible validate the federation, click and go to AGS Manager, use Survey123 etc. In the code (using the inspect option) we have two alerts (one related to a token url and one about an image), but the rest works normally.

Thanks @ChristopherPawlyszyn for your comments and ideas.

Regards.

[Todd]

@lvargas we are having a similar issue. We've abandoned use of the web adaptors since we have a reverse proxy server available. However, the documentation for configuring a proxy server on Linux is much to be desired. We still have several instances where /arcgis/ points to  /portal/ which have been handled in a config file. This includes handling of new user accounts, REST services, creating feature services, etc.

It doesn't make much sense to have to add so many ProxyPassReverse settings to get the system to function.