nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Bereitstellungsmuster zum Exponieren von ArcGIS Enterprise gesicherten Diensten für externe Benutzer

NoahMayer

Einführung

Sicherheit spielt eine große Rolle im Prozess der Unternehmensarchitekturgestaltung. Sicherheitsrichtlinien variieren zwischen Organisationen, und unterschiedliche Bereitstellungsmuster sind erforderlich, um diese Anforderungen und Einschränkungen zu erfüllen. In diesem Beitrag werde ich versuchen, einige der häufigeren Sicherheitsbeschränkungen anzusprechen und Bereitstellungsmuster vorzuschlagen, um diese zu erfüllen.

Dies ist keinesfalls eine vollständige Liste aller verfügbaren Sicherheitsanforderungen und Sicherheitsarchitektur-Muster.

Dieser Beitrag konzentriert sich auf Architektur-Muster, um ArcGIS Enterprise gesicherte Ressourcen für externe Clients zugänglich zu machen, d.h. Systeme mit der Anforderung, außerhalb des internen Netzwerks der Organisation über eine DMZ zugänglich zu sein, z.B. zur Unterstützung des Zugriffs von Außendienstmitarbeitern ohne VPN.

Es gibt zusätzliche Überlegungen, die bei der Entscheidung für ein Muster eine Rolle spielen, die in diesem Beitrag nicht behandelt werden, wie z.B. wie viele Ressourcen, z.B. Hardware, Lizenzen und Personal, für jedes Muster benötigt werden.

Um den Sicherheitsaspekt des Architektur-Musters zu vereinfachen und zu fokussieren, sind alle Architekturen in diesem Beitrag nicht hochverfügbar, aber jede kann zu einer hochverfügbaren Architektur angepasst werden, ohne das Muster zu ändern.

DMZ Reverse Proxy

Lassen Sie uns mit dem am häufigsten eingesetzten externen ArcGIS Enterprise System-Bereitstellungsmuster beginnen, bei dem ein Reverse Proxy in der DMZ verwendet wird.

Abbildung 1 - DMZ Reverse Proxy

Abbildung 1 - DMZ Reverse Proxy.PNG

In diesem Muster werden alle ArcGIS Enterprise Komponenten im internen Netzwerk hinter der Firewall gehostet, und ein Reverse Proxy (dies kann ein kommerzieller Reverse Proxy wie F5 oder NetScaler sein, ein Open Source Reverse Proxy wie Nginx oder HAProxy oder ein zweites Set von ArcGIS Web Adaptors) wird in der DMZ bereitgestellt und leitet externe Anfragen an ArcGIS Enterprise weiter.

Das ArcGIS Enterprise Portal unterstützt nur einen DNS für die öffentliche Portal-URL (die Web-Kontext URL), und um externen Zugriff zu ermöglichen, muss ein extern auflösbarer DNS-Name für die Web-Kontext URL des Portals verwendet werden, z.B. https://gis.company.com/portal.

In den meisten Fällen beinhaltet das oben genannte Muster die Implementierung eines Split Domain Name Systems (Split DNS), d.h. interne Anfragen an den ArcGIS Enterprise DNS (z.B. gis.company.com) werden auf die IP des internen Web Adaptors aufgelöst, sodass interne Benutzer hinter der Firewall bleiben, und externe Anfragen an den ArcGIS Enterprise DNS werden auf die IP des DMZ Reverse Proxys aufgelöst.

Die Verwendung einer Web Application Firewall (WAF) vor dem DMZ Reverse Proxy ist eine bewährte Sicherheitsmaßnahme, da sie zusätzliche Sicherheitskontrollen hinzufügt. Esri pflegt ein Dokument (organisatorische Anmeldung erforderlich) unter https://trust.arcgis.com mit einer Liste von Endpunkten, die sicher vom externen Zugriff gefiltert werden können, um den externen Zugriff auf potenziell sensible Ressourcen in Ihrer ArcGIS Enterprise Site zu verweigern.

Besondere Sicherheitsbeschränkungen

Kein nicht authentifizierter Zugriff auf das interne Netzwerk

In einem föderierten ArcGIS Enterprise System ist das Portal für die Benutzerauthentifizierung und -autorisierung verantwortlich. Im oben genannten Muster prüft ArcGIS Enterprise bei einer Anfrage an eine gesicherte Ressource (z.B. Dienst) zunächst, ob gültige Authentifizierungsinformationen enthalten sind. Falls nicht, gibt ArcGIS Enterprise eine Weiterleitungsantwort an den Client zurück, um sich beim konfigurierten Identitätsanbieter zu authentifizieren, z.B. SAML oder OpenID Connect.

In der oben beschriebenen Architektur wird eine nicht authentifizierte Anfrage von einem externen Client vom DMZ Reverse Proxy an einen internen Web Adaptor weitergeleitet und von dort an das ArcGIS Enterprise Portal oder den Server weitergegeben, bevor ArcGIS Enterprise eine Weiterleitungsantwort an den Client zurückgibt.

Einige Sicherheitsrichtlinien verbieten nicht authentifizierten Zugriff auf die Intranet-Zone, daher erfüllt die oben beschriebene Architektur diese Einschränkung nicht.

Kein HTTPS-Zugriff / Nur Datenbankzugriff ist von der DMZ zum internen Netzwerk erlaubt

Die meisten Sicherheitsrichtlinien erlauben eingehenden Zugriff von der DMZ zum internen Netzwerk, können jedoch den Typ des erlaubten Zugriffs nach Protokollen oder Ports einschränken. Beispiele wären kein HTTPS (Hypertext Transfer Protocol Secure) Zugriff von der DMZ zum Intranet oder nur Datenbankzugriff über benutzerdefinierte Ports zu erlauben.

In der oben beschriebenen Architektur leitet der DMZ Reverse Proxy die Anfragen über HTTPS über Port 443 an ArcGIS Enterprise weiter, was diese Einschränkung nicht erfüllt.

Kein eingehender Zugriff von der DMZ zum internen Netzwerk

In einigen Fällen verbieten Sicherheitsrichtlinien jeglichen eingehenden Zugriff von der DMZ zum internen Netzwerk und erlauben nur nicht persistente Verbindungen vom Intranet zur DMZ.

Sicherheitsarchitektur-Muster

Betrachten wir die folgenden Sicherheitsarchitektur-Muster und prüfen wir, wie jedes Muster einige oder alle der oben besprochenen Sicherheitsbeschränkungen adressiert.

DMZ ArcGIS Enterprise Portal und registrierte Dienste

Proxy.PNG" style="width: 628px;"> Figure 2 - ArcGIS Enterprise Portal Proxy.PNG

<\/span><\/P>

<\/DIV>

In Abbildung 2 oben befindet sich ein ArcGIS Enterprise-Portal in der DMZ und ein ArcGIS Enterprise-Server im internen Netzwerk. Der interne eigenständige Server ist nicht mit dem Portal föderiert – Dienste werden direkt auf dem eigenständigen Server veröffentlicht, der als gesichert im Server mit einem Anwendungskonto (ArcGIS Enterprise server built-in application account oder Active Directory \/ LDAP service account) konfiguriert ist, und dann als Elemente aus dem Web zum Portal hinzugefügt werden<\/A> mit gespeicherten Anmeldeinformationen. Wenn ein gesicherter ArcGIS Enterprise-Serverdienst im Portal mit gespeicherten Anmeldeinformationen registriert wird, erstellt das Portal eine Proxy-URL für diesen Dienst, und alle Anfragen an diesen Dienst werden über das Portal geleitet, bevor sie an den internen eigenständigen Server weitergeleitet werden. Das ArcGIS Enterprise-Portal ermöglicht es Ihnen auch, eine Ratenbegrenzung und spezifische Referrer zu definieren, die auf den Dienst zugreifen können<\/A>.<\/P>

Die Verwendung des obigen Musters erfüllt die Einschränkung, dass kein nicht authentifizierter Zugriff auf das interne Netzwerk möglich ist, da alle externen Anfragen das Portal in der DMZ passieren müssen, das zuerst den Benutzer authentifiziert und autorisiert und erst dann eine Anfrage an den Dienst im internen Netzwerk stellt. Beachten Sie, dass Sie durch die Verwendung gespeicherter Anmeldeinformationen für alle Anfragen vom Portal zum Server die Fähigkeit zur Editorverfolgung verlieren.<\/P>

Die Architektur in diesem Muster kann erweitert werden, um ein intern ausgerichtetes föderiertes System von ArcGIS Enterprise mit Portal, Hosting-Server und föderierten Server(n) einzuschließen, wie in Abbildung 3 dargestellt.<\/P>

<\/P>

Abbildung 3 - ArcGIS Enterprise Portal Proxy Ausgearbeitet<\/H3> <\/P><\/span><\/P>Internes Repliziertes Geodatabase<\/H2> <\/P>Die Sicherheitsrichtlinien einiger Organisationen erlauben keinen HTTPS-Zugriff von der DMZ auf das Intranet und erlauben nur Datenbankzugriff, üblicherweise über Nicht-Standardports, und in vielen Fällen auch keinen externen Zugriff auf eine primäre Produktionsdatenbank und verlangen die Nutzung einer separaten Datenbank.<\/P>In Abbildung 4 unten ist ArcGIS Enterprise in der DMZ bereitgestellt, und eine intern replizierte Unternehmens-Geodatabase wird als registrierte Datenquelle für den Mapping-Server verwendet. Es kann entweder Esri-Geodatabase-Replikation oder RDBMS-Replikation verwendet werden.<\/P> <\/P>Abbildung 4 - Datenbankreplikation<\/H3> <\/P><\/span><\/P> <\/DIV>Abbildung 5 unten zeigt eine ausgearbeitete Architektur, die ein intern ausgerichtetes ArcGIS Enterprise-System im internen Netzwerk und ein extern ausgerichtetes ArcGIS Enterprise-System in der DMZ umfasst.<\/P> <\/P>Abbildung 5 - Datenbankreplikation Ausgearbeitet<\/H3> <\/P><\/span><\/P> <\/DIV>Dienstveröffentlichung und Zusammenarbeit<\/H2> <\/P>Schließlich zeigt Abbildung 6 unten für diejenigen, die keinen eingehenden Zugriff von der DMZ auf das Intranet zulassen, ein extern ausgerichtetes ArcGIS Enterprise in der DMZ und ein intern ausgerichtetes ArcGIS Enterprise im Intranet mit:<\/P>Diensten, die als gehostete Layer im DMZ ArcGIS Enterprise-System veröffentlicht werden, und automatisierten Aufgaben, die nach Zeitplan (z.B. nachts oder wöchentlich) laufen, um die gehosteten Daten zu überschreiben<\/A> mit aktualisierten Daten aus dem internen ArcGIS Enterprise-System<\/LI>Feature-Layer werden per Kopie vom internen ArcGIS Enterprise-System zum DMZ ArcGIS Enterprise-System über verteilte Zusammenarbeit mit bidirektionalem gemeinsamem Bearbeiten<\/A> (eingeführt in Version 10.9) geteilt<\/LI><\/>OL>
<\/>P>

Abbildung 6 - Dienstveröffentlichung und Zusammenarbeit<\/>H3><\/>P> <\/>P>

Einschränkung des Zugriffs externer Anwendungen auf ArcGIS Enterprise

In einigen Fällen verwenden Organisationen ArcGIS Enterprise zur Unterstützung externer integrierender Anwendungen und möchten den Zugriff externer Anwendungen einschränken, indem sie externe Anfragen filtern und nur Anfragen von einer bestimmten Liste oder einem Bereich von IPs oder von bestimmten Domains zulassen.

ArcGIS Online Proxy

Ähnlich wie beim Muster DMZ ArcGIS Enterprise Portal und registrierte Dienste (Abbildung 2 oben) fungiert auch ArcGIS Online als Proxy, wenn Sie gesicherte Dienste entweder von einem eigenständigen ArcGIS Enterprise-Server oder von einem föderierten ArcGIS Enterprise-System registrieren. In Abbildung 7 unten sind Dienste eines internen ArcGIS Enterprise-Systems in ArcGIS Online mit gespeicherten Anmeldeinformationen registriert. ArcGIS Online kann über den DMZ-Reverse-Proxy auf die Dienste zugreifen, wobei der Reverse-Proxy so konfiguriert ist, dass er nur Anfragen von der Domain von ArcGIS Online zulässt und Anfragen von anderen Quellen blockiert. Das integrierende System-Web- oder Mobile-App kann bei ArcGIS Online unter Verwendung von OAuth 2.0 und ArcGIS Identity<\\/A> registriert werden, sodass nur authentifizierte und autorisierte Benutzer auf die registrierten Dienste zugreifen können. Da ArcGIS Online die Dienste mit gespeicherten Anmeldeinformationen aufruft, funktioniert die Editorverfolgung nicht. Ähnlich wie beim Portal können Sie eine Ratenbegrenzung sowie spezifische Referrer definieren, die auf die Dienste zugreifen dürfen.<\\/p>

<\\/p>

Abbildung 7 - ArcGIS Online und registrierte Dienste

Serverproxy

Ein anderer Ansatz wäre die Verwendung einer eigenständigen ArcGIS Enterprise-Server-Site und eines Serverproxies zum Zugriff auf gesicherte Dienste aus einer integrierenden Web-App.
In Abbildung 8 unten sind Clients der integrierenden System-Web-App so konfiguriert, dass GIS-Anfragen an einen Proxy gesendet werden, der auf dem Anwendungserver des integrierenden Systems gehostet wird. Der Anwendungserver des integrierenden Systems ist verantwortlich für die Sicherung des Zugriffs auf den Proxy, d.h., es dürfen nur app-authentifizierte Benutzer auf den Proxy zugreifen, und er schützt (verschlüsselt) die Anmeldeinformationen des ArcGIS Enterprise Servers. Der Proxy verwaltet die Token-Sicherheit des ArcGIS Enterprise Servers im Auftrag des Clients unter Verwendung eines serverinternen Anwendungskontos oder eines Active Directory \/ LDAP-Dienstkontos und sendet die Anfrage über den DMZ-Reverse-Proxy an die interne eigenständige ArcGIS Enterprise Server-Site. Der Reverse-Proxy ist so konfiguriert, dass er nur Anfragen von IPs (Liste oder Bereich) des integrierenden App-Servers zulässt und Anfragen von anderen Quellen blockiert.

Abbildung 8 - Integrierender Web-App Serverproxy

role="button" title="Abbildung 8 - Integration des Web App Server Proxy.PNG" alt="Abbildung 8 - Integration des Web App Server Proxy.PNG" \/><\/span><\/P>

<\/P>

Finde mehr Beiträge mit dem Tag

Configuration & Integration

Architecture & Security

Kommentare

NoahMayer

@spanton you nailed it. You want to expose ArcGIS Enterprise secured resources to external clients when they can't use VPN for any reason.

spanton

Hello @NoahMayer , what would be a common use cases for exposing ArcGIS Enterprise secured resources to external clients? We currently have a DMZ in place but are considering doing away with it; currently our field crews access our maps via VPN.

SimonSchütte_ct

Thank you, I´ll have to give it a try.

DavidHoy

If you were allowing CORS requests to your Portal from AGOL,
you would add the following to your AllowedOrigins

perhaps both these should be allowed and included in the list of URLs allowed to access your proxied service?

NoahMayer

Related to the remote address {someipaddress}:443 requesting access to the internal endpoints: ArcGIS Online uses dynamic IPs, but you should not see requests coming from ArcGIS Online using IP address. Can you test allowing access only from {subscription}.maps.arcgis.com and see if it allows access via the ArcGIS Online proxy?

SimonSchütte_ct

@NoahMayer These are my findings on ArcGIS Online <-> ArcGIS Enterprise Communication:

ArcGIS Online {subscription}.maps.arcgis.com will try to access
machinename.example.com/server/...
and
machinename.example.com/portal/...

Communication is initiated by {subscription}.maps.arcgis.com
and another remoteaddress {someipaddress}:443 (is it a fixed or dynamic IP? generic for ArcGIS Online or specific to subscription?)
requesting access to the internal machinename.example.com server/portal endpoints.

Communication is done using HTTPS: GET, HEAD, POST, OPTIONS

NoahMayer

@SimonSchütte_ct It definitely makes sense that in this use case only a subset of ArcGIS Online domains will be used. If you want to narrow down the list of allowed domains, it will require some testing to find out which domains are used in this use case.

SimonSchütte_ct

ArcGIS Online as Proxy: How to allow access only to requests from ArcGIS Online domain?

@NoahMayer Is there a list of the specific domains that need to be configured? In ArcGIS Trust, there is a document for the WAF and allowed ArcGIS Online domains, but there is nothing mentioned regarding which domains are relevant for this use case.

Some more details on the actual setup and configuration would be appreciated.

NoahMayer

@GeoExplorer
I'm not in a position to say if a two-way replication is more of a problem/threat compared to a one-way replication from corporate database to the database in DMZ and ETL from the database in the DMZ to the corporate database. This is up to your security team to decide. If they have specific questions regarding how the Esri software works, or if they are willing to share their concerns, Esri PS can try to answer their questions and help them with their decisions.

DavidHoy

Hi @GeoExplorer
it would be possible to have 2-way geodatabase replication using a geodata service running on the internal ArcGIS Server. This would only require 443 access through the internal firewall. The synchronisation would be triggered by a python script running on the Server in the DMZ. The python script would require a geodatabase connection (via Oracle client) to the DMZ Geodatabase but a geodata service connection to the "master"geodatabase within the secure network.

GeoExplorer

Dear @NoahMayer,

Thank you for your response.

Cyber Security team in our Organisation has put two-way replication on hold, mentioning no communication from database in DMZ to corporate database network. But approved using one-way replication from corporate database to database in DMZ, which is disconnected replication that is batched to sync overnight.

Do you reckon it is really a problem/threat in enabling two-way replication as compared to One-way replication via custom port (1521)? Suggestion from the cyber security team is to write ETL scripts to bring down the necessary data collected by field users from the DMZ database to the corporate database.

NoahMayer

Dear @GeoExplorer ,

What are the concerns you have regarding using a two-way replication? In general I would prefer to use geodatabase replication over ETL where available, since geodatabase replication has a robust set of capabilities, such as viewing and resolving conflicts, which might be very challenging with ETL. Depending on the concerns you have, you might opt-in to use disconnected replication instead of connected replication.

GeoExplorer

Hello Noah,

Thank you for providing the various deployment patterns that suit our organization's needs.

We are working on a design to facilitate an external-facing ArcGIS Enterprise to enable field crews to connect and share data via collaboration with external government agencies.

We were considering the architecture provided in Figure 5 of the document you mentioned. Our architecture team suggested placing the replicated geodatabase in the DMZ via port 1521 and running nightly replication instead of hosting it in the corporate network. We are using Oracle database, so allowing port 1521 or any other custom port to let replication work. Noting data is 24 hour delay to external ArcGIS instance.

Could you please advise on the issues associated with having a replicated Oracle database in the DMZ and enabling ArcGIS replication? Is allowing two-way replication a threat? One suggestion is to enable only one-way replication from the internal geodatabase to the external database in the DMZ and to write ETL scripts (FME) to fetch the data from the external database.

ArcGIS Enterprise 10.9.1

Oracle DB - 19c

NoahMayer

@vijaybadugu,

Portal for ArcGIS does not support changing/setting the WebContextURL for an existing ArcGIS Enterprise system that has content, because all the original items have the old, internal domain URLs, and all those will have to be updated to the new DNS alias.

The Services URL in the federation will have to be updated with the new DNS alias because this is how all users will access the services. External users will not be able to resolve your internal domain URLs.

I recommend you collaborate with Esri professional services to assist you with this process.

vbadugu_royomartin

I removed user and group store configurations as I'm using SAML authentication. as I mentioned earlier, It is federated with server,

Service URL

https://<Internal domain> /arcgis

Administration URL

https://<Internal domain>:6443/arcgis

as per old configurations, I did not change anything and anywhere except WebContextURL in arcgis portal admin.all are pointing to internal domain reference.

For above Server Configurations Do I need provide DNS alias or internal domain ?

Every time, I click on Organization tab in ArcGIS Portal, it displays a dialog to sign in. can we bypass this ? after clicking ok, it automatically signed in.

We have a Web application and in that, all map services are pointing to <internal domain>/rest/services/<Service Name>/MapServer. Do I need to change all map services URLs to DNS alias instead of internal domain that we were using till now?

Thanks

DeanMoiler

Hi @vijaybadugu,

You can apply your SAML username to existing users to allow SAML login if you don't want to migrate content / create / delete users. More info here:

Solved: Re: Change Authentication from IWA to other method... - Esri Community

As @DavidHoy says, this won't change the user's username, but it will allow existing users to log in with SAML.

We investigated creating a new domain attribute to hold username@domain to keep this naming format, as we had thousands of users, and have new users created in this format, but the overhead for this attribute was passed over in favour of creating new users with new username format and migrating content and users by script.

vbadugu_royomartin

Can I make both as empty (user store and group store ) ?

DavidHoy

If you just switch to using SAML login, you are correct that new users may appear in your Portal for the <usrname>@domain.net username provided by Azure AD as they start to login (if you have automatic user creation enabled)

There is no back-door way to update existing users to have a new username.

You will need to transfer any content owned by the existing usernames <usrname>@domain to be owned by the new names.

We have handled this by scripting
- create the new users and assign the new users the appropriate type and role
- assign the new usernames to the Groups to match the old username
- transfer ownership of any Portal items to the new user
- disable the existing Username (remove in future)

Once this is complete, the first time a user logs in via SAML, they will find their new username is in place

You cannot have IWA and SAML working at the same time, so User Store Configuration and Group Store configuration cannot be "WINDOWS"

vbadugu_royomartin

Have a another question regarding content transfer, The current user format with IWA is <usrname>@domain. when I moved from the AD to Azure AD, The format of username would be changed to <usrname>@domain.net (email format). How do I transfer the content to new user ? is there a way to update enterprise user without transferring the content ? and we have a bunch of users. when comes to the identity store, can I keep same what it is now "windows" in portal admin

User store configuration:

{ "type": "WINDOWS"

Group store configuration:

{ "type": "WINDOWS",

? do i need to change anything? Actually I disabled the windows authentication and enabled Anonymous enabled.

NoahMayer

@vijaybadugu Yes definitely. SAML and OpenID Connect logins are recommended.

vbadugu_royomartin

We have configured AZURE AD for authenticate SAML for internal and external. is that best practice to go farward

DavidHoy

hi Vijay,

your plan is sound - a split-zone dns arrangement would certainly allow the ArcGIS Enterprise to work for external and internal users.

There are many forms of DNS, so, it is difficult to provide instructions here unless you can be more specific. A bit of web searching for the doc for your particular DNS provider should get you there.

If you cant work it out - it is not a critically bad thing to allow your internal users to have everyone have the FQDN resolve to the Reverse Proxy.

NoahMayer

Hi @vijaybadugu,

What you are describing is a Split (or Split-Brain) DNS configuration: in this configuration, as you described, internal users are directed to the internal server IP (which is a private IP) and external users are directed to the DMZ reverse proxy IP (which is a public IP). The actual configuration depends on how your organization configures DNS.
In many cases, organizations will have:
1. Internal DNS servers, where they would configure A-Records and CNAME records for their internal domain, for example:
A Record: machine1.company.int --> <Machine Internal IP>
CNAME Record: maps.company.com --> machine1.company.int
2. Public DNS service, such as Google or Cloudflare, where they would configure an A Record for the external users, for example:
A Record: maps.company.com --> <DMZ Reverse Proxy Public IP>

In this configuration, all internal users, since they are on the internal network, which is configured to use the internal DNS servers for name resolution, will be directed to the internal server, and all the external users, since they are coming from the Internet, will be directed to the DMZ reverse proxy.

vbadugu_royomartin

I have Question regarding configuration of DMZ with Single machine Deployment, we have been struggling to configure reverse proxy for ArcGIS Enterprise. We recently Upgraded the Enterprise to 11.1. All components are on Same Windows Server (2 WA's, Server, Data store and Portal) Federated IWA. We have Configured the load balancer on DMZ Server and open the 443 to route the traffic from DMZ Server. Here is the Our Requirement, Suppose User or member accessed the URL from External, It should route from the DMZ (Split DNS). If user Accessed from Internal network, it should hit Direct server instead of Routing From DMZ. Is this Possible ? If yes, How I need to configure those ? Please help us .

JeffDeWeese

The only publicly available icons I am aware of are here, but they lack the server type icons, etc.: https://community.esri.com/t5/implementing-arcgis-blog/esri-presentation-icons/ba-p/886935

NoahMayer

@JeffDeWeese can you help?

BrianVillanueva

Hi @NoahMayer , where can I find the stencils used in the diagrams?

MehdiPira1

Very helpful, Thanks @NoahMayer .

NoahMayer

Hi @MartinWennerwald1!

Esri is maintaining an ArcGIS Online domain requirements document in ArcGIS Trust Center. There are tow versions of the document:

Public document (less detailed): https://trust.arcgis.com/en/documents/AGOL_Domain_Requirements.pdf

Customer Accessible Document (more detailed, requires login): https://trust.arcgis.com/en/customer-documents/ArcGIS%20Online%20FQDN%20Requirements%20V1.8%20June%202021.pdf

This document is intended mainly for a forward proxy, to allow users to access ArcGIS Online resources, so you can see the list beyond what's required for setting up the ArcGIS Online Proxy (Fig. 7).

What I would recommend is to view the service URL in the portal item which is created for the registered services, this URL is the proxy URL, and allow only the FQDNs which are used for the proxy:

MartinWennerwald1

Hi Noah

Thanks for a great detailed article.

We are currently working on setting up the ArcGIS Online Proxy setup (Fig. 7), but can't seem to find information on which domains to limit access to. In your article you write : "ArcGIS Online can access the services via the DMZ reverse proxy, and the reverse proxy is configured to allow requests only from ArcGIS Online domain, blocking requests from any other sources."

Where do I find the documentation for what the "arcgis online domain" consists of, specifically with regards to registered services?

Thanks in advance.

/Martin

Nehmen Sie an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registrieren Sie ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.