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; } } }

Public access to internal Enterprise deployment with anon access enabled, setup strategies

DavidPersson

Hi, our org has deployed an Enterprise 10.8.1 base setup with a SAML idp.

The web adaptors for the federated hosting server as well as the Portal are installed on a machine in the DMZ part of the org network (though not publicly available). We've currently evaluating the environment for internal use but have preliminary hopes of using one Enterprise deployment for both organization users, in the field and on the company network, as well as making everything shared with "everyone" and Public available to the general public.

When attempting to research how one would setup the following, if it's at the minimum case enough to expose the Portal web adaptor url, I've found the high availability setup scenarios ( https://enterprise.arcgis.com/en/portal/latest/administer/windows/ha-scenarios-web-gis.htm ) as well as the Security Best Practices ( https://enterprise.arcgis.com/en/portal/latest/administer/windows/security-best-practices.htm ) that mention that anonynous access is best left off.

So being aware that we would obviously need to make sure the right users/roles had "share things to the Public" and that we are planning to start small in terms of users and data, having a part exposed externally is nevertheless going to need following one of the HA scenarios I think, as the Enterprise deployment possibly/probably becomes mission critical; correct?

Our initial plan was for an unfederated ArcGIS Server to supply AGOL with services for the general public but we have initially rejected that idea in order to administer only one Portal environment and also because there are currently some not entirely resolved questions regarding GDPR.

Thanks for reading and for any pointers on further (mandatory) reading : )

Find more posts tagged with

Accepted answers

All comments

ReeseFacendini

A highly available (HA) setup means that Portal, ArcGIS Server, and DataStore have standby instances in case the primary instances suddenly stop functioning. From your post, you are wanting info, or recommendations on how best to serve content to within the org network and outside of it right? HA will work in every scenario that a general base deployment does, and doesn't offer any additional functionality serving up content.

DavidPersson

Hi,

@ReeseFacendini wrote:
A highly available (HA) setup means that Portal, ArcGIS Server, and DataStore have standby instances in case the primary instances suddenly stop functioning. From your post, you are wanting info, or recommendations on how best to serve content to within the org network and outside of it right? HA will work in every scenario that a general base deployment does, and doesn't offer any additional functionality serving up content.

Yes, this is correct.

@ReeseFacendini wrote:
A highly available (HA) setup means that Portal, ArcGIS Server, and DataStore have standby instances in case the primary instances suddenly stop functioning. From your post, you are wanting info, or recommendations on how best to serve content to within the org network and outside of it right? HA will work in every scenario that a general base deployment does, and doesn't offer any additional functionality serving up content.

Indeed, I mentioned it because I've found few other articles discussing and internal/external Enterprise deployment and because when the Enterprise eventually becomes mission critical we will need to minimize downtime. That might not mean either of the HA-deployments listed, I don't profess to know at the moment.

ReeseFacendini

One thing to keep in mind is that once you have chosen a URL for your deployment, it can't be changed without breaking published services or other Portal content (maps, applications, etc.). If it's possible, I would make the system public facing now, then restrict access to that URL. When you are ready to have the general public access items, remove the restriction.

dewright_ca

Hi David.

What I built in my environment is a separate Portal instance for PUBLIC access; then established a collaboration between my INTERNAL Enterprise platform and the PUBLIC side.

This allows me to create a way to push/expose the services/functions that I want outside my enterprise while letting the ESRI stack handle the proxying of the requests.

crussell_esriau

Hi David

You are correct in that you'll need to follow one of those HA patterns for external access (specifically the SAML ones given that this is your IDP), even if your deployment isn't actually HA. Apart from the HA scenarios, I can't recall seeing any comprehensive documentation which covers public/external access.

Conceptually you can look at the "load balancers" in the diagrams as being something like a gateway or reverse proxy for a non-HA scenario, it is ultimately serving the same purpose as a true load balancer (like F5 BIG IP). The ArcGIS web adaptors themselves can also technically act as the reverse proxy, being exposed to the public via the DMZ and obscuring the backend.

Some key things which may not be obvious from the diagrams/documentation are:

Portal and server need to communicate with each other over ports 7443/6443, and for security/performance purposes this should all happen behind your firewall (if the admin URLs used for federation are the 6443/7443 ones then you shouldn't have an issue here)
Admin access to ArcGIS Server needs to be disabled on the server web adaptor
You will see that neither of the SAML scenarios has a web adaptor for Portal; this is optional, but it is generally less complicated to have a web adaptor in the mix (especially if you've already set up using one)

In your OP, you mentioned this:

When attempting to research how one would setup the following, if it's at the minimum case enough to expose the Portal web adaptor url, I've found the high availability setup scenarios

You'll need to expose both the Portal and Server web adaptors to the public, otherwise users will be able to browse Portal content without being able to draw anything in maps or access services.

Also regarding disabling anonymous access, this means that unauthenticated users won't be able to browse your portal, see featured content etc. If this is something that you require for the public, then you could use the Sites feature to create a publicly accessible hub-type page for this sort of thing.

Hope this helps!

Craig

DavidPersson

Hi, good point. Right now everyone accesses the portal via the webadaptor URL, which is in the DMZ and has a public certificate. (There's a firewall in front of and behind it), so I suppose unless we have to rearrange things severely, that this is currently the case.

DavidPersson

Hi, that's an interesting suggestion. Most / all items in the external Portal instance are Public/shared to all and it has anonymous access enabled, whereas the internal one probably doesn't?

I'll read up on collaborations and how items can be shared between them. Separate access points for public visitors and IDs of the internal Portal I suppose and if access to the internal one in the field, do you employ a VPN solution?

DavidPersson

Hi, thanks very much for the detailed response!

The admin url used for the federation of the hosting server is :6443.If other servers/roles they should follow this example I take it. (The only other server we have federated, an ImageServer, is not federated via its :x443 address because that gave us issues in a citrix environ..we are currently transitioning away from said environ however and I understand from your post that it's better to not use the fweb adaptor adress for the admin url when fedearing for security purposes)

Good point about both Portal and hosting server web adaptors being needing to be exposed publicly : )

"The ArcGIS web adaptors themselves can also technically act as the reverse proxy, being exposed to the public via the DMZ and obscuring the backend." They are installed in the dmz server with a public certificate domain, so "public.domain.se" -> 6443/7443 -Enterprise base install machine via the web adaptors. Theres a firewall behind and in front of this DMZ machine so nothing is exposed publicly yet but it should be theoretically prepared, as I parse your reply. Can this be considered realistic for a small-scale start?

"If this is something that you require for the public, then you could use the Sites feature to create a publicly accessible hub-type page for this sort of thing." -

If anon access on in order to facilitate public visits, ie no login required, for publicly shared items, we can direct such visits to a or several Sites, I take it. Good advice, I shall look into that.

To all: I really like this forum for the fast and intelligent answers one can get : )

dewright_ca

In truth; I actually have 2 externally facing Portals. 1) is Totally anonymous and publicly shared; 2) uses my states Single-Sign-On to access secured services that are not for public consumption.

So both portals see like my Basemaps group and content for Webmaps; but then seperate groups are used to shared/host data between the PUBLIC and SECURE face.

But everything is managed through my Internal Enterprise stack.

crussell_esriau

...we are currently transitioning away from said environ however and I understand from your post that it's better to not use the fweb adaptor adress for the admin url when fedearing for security purposes

It shouldn't use the same web adaptor as the one being used for end user access. You can have a separate web adaptor for admin traffic with elevated security in some circumstances, but for what you're proposing, the 6443 direct one is probably the way to go.

They are installed in the dmz server with a public certificate domain, so "public.domain.se" -> 6443/7443 -Enterprise base install machine via the web adaptors. Theres a firewall behind and in front of this DMZ machine so nothing is exposed publicly yet but it should be theoretically prepared, as I parse your reply. Can this be considered realistic for a small-scale start?

Should be fine, provided that your IT security team has no qualms about using third party components like the web adaptors in your DMZ, this sort of thing comes up sometimes and ultimately you have to work within your organizations IT principles. What's important to note is that if for some reason you end up putting a gateway/reverse proxy between the internet and your web adaptors, the public URLs/DNS entries must be the same as what you've used for the web adaptor URLs to avoid having to unfederate/refederate.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

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