Best Practices for Portal Access for both Private and Public Services

[DMOB17]

ArcGIS Enterprise version 10.9.1

We currently have two installations of ArcGIS Server running. One ArcGIS Server site on a dedicated machine that is used as an internal-only access server and is not running any web adaptor, and another instance of ArcGIS Server that is federated with Portal with a web adaptor installed on a web server on the DMZ to allow public access to services we publish.

This seems like overkill considering we are a very small city government agency and have very few services published to each of these sites. The reason we set up an internal-only server installation was to publish XY event services we use to create apps/dashboards that our employees can access without logging in as long as they're on our network. We set up the federated environment to share services with third-party software companies that we integrate our GIS data with.

Is there a way to host all of our services on the server that is federated with portal to cut down on the number of GIS machines we're maintaining, or does having the publicly available web adaptor diminish our ability to secure our services enough if we wanted to maintain some internal-only services? I understand we can configure some services to require logins through our portal but I'm wondering if you can set up access in a way that allows sharing services to internal users publicly while not allowing public users to access them.

Just looking for best practices here.

[ThomasM]

In a very similar situation, and, as far as I can tell, to share items with your internal users without sharing publicly, each person would need an account on your Portal. If they only need viewer access, Enterprise comes with unlimited Viewer licenses; you'd just have to add those people. If people inside your organization need to be able to edit the data, then they'd need a Creator or GIS Professional license. Enterprise comes with a set of Creator licenses, but additional ones will have to be purchased.

One work around having the accounts might be to use the limit usage options available when publishing a secured service. You would nee to serve that content on an intranet and limit the usage of those layers to the intranet site. However, I'm not sure if limiting usage is available when you publish through a federated server. Best of luck!

[jcarlson]

Here in Kendall County, we've got a handful of internal layers that need to be secured, but also a lot of public items. We serve everything through our Portal, utilizing Named User accounts, as @ThomasM  mentions. We have enough licenses to cover our users, and are in no way hindered by serving everything through a single server.

[TonyContreras_Frisco_TX]

1. If you want the internal users to be able to see sensitive information without logging in, the most secure method would be to keep one GIS server internal only that is not federated with Portal or using a DMZ Web adaptor.
2. For security purposes, and to comply with the latest security standards, you really should secure the services anyway, even if they are on your network. You do not want your department or group to be seen as the weak link, especially when an attack is successful and an investigation shows the vulnerabilities that could have been prevented.

If setting up and maintaining named/built-in users is one of the big deterrents to securing the services, I recommend setting up your portal with a SAML provider,if you have one to use. That way, the users are managed somewhere else and users can log in via clicking a button on the log in page.

[DMOB17]

Thanks Tony. Great information provided here.

Do you know if there are configurations available to enable SAML authentication and also allow public services, i.e. any services that aren't shared publicly require SAML login while any services shared publicly do not?

[ThomasM]

In your Portal, under Settings -> Security, if you have "Allow anonymous access to your portal" enabled, then anything that has sharing set to "Everyone" will be viewable by the public without having to sign into the Portal. If that is disabled, users will have to login even if an item is shared to Everyone. If you set an item's sharing to "Organization", users will need to sign in to view it no matter whether the anonymous access is enabled or not.