One of the most challenging topics when implementing the Esri platform is how authentication will be handled. Are you curious about your authentication options? There are significant implications around ArcGIS Online and/or Portal that will be driven by your decisions on this topic.
Within this video, SSP Innovations’ Skye Perry details the most popular options surrounding authentication for your portal.
Is your utility, telecommunications company, or pipeline operation interested in getting up and running on ArcGIS Online, ArcGIS Enterprise, and/or Portal for ArcGIS? Learn about the ArcGIS Online Jumpstart option from SSP on our GIS Jumpstarts overview page here. We’ll get your team up and running quickly on the leading Esri web GIS platform.
Hi, I’m Skye Perry with SSP Innovations and today I wanted to explore a topic we get a lot of questions on when discussing options around going with Esri ArcGIS Online or Esri Portal for ArcGIS.
One of the major areas that we think you need to make this decision on is authentication. And so I wanted to come in here today and talk a little bit about authentication options for Esri ArcGIS Online and Esri Portal for ArcGIS, just so that it might help in your decision making.
So I’ve got a pre-drawn board here. We’ve got ArcGIS.com, which is Esri ArcGIS Online, drawn out here. I’ve also got Portal. I’ll come back to Portal in a moment. I’m not really focusing on architecture as far as getting to the geodatabase, but I kind of just represented that from our other architectures. ArcGIS.com can go through a DMZ Web Adaptor and get to the back-office geodatabase. We’ll assume it has data.
So let’s focus in on the authentication options for Esri ArcGIS Online. Now the easiest approach, and what we’ve done with 99% of our customers who have implemented ArcGIS.com, is to use the native local user store. So when we say local users, when you create your Esri ArcGIS Online organization, you, by default, have a user within that organization, and we can then go ahead and create additional local users. Here at SSP, we use firstname.lastname_SSP. So, I could create one of those for every user in my company here, and provide them access.
Now, the upside of this is I could do this in minutes, literally minutes. I can upload it from a file. I could type it in and it does not take very long. It will assign them a password initially, as they start to sign-up, and then they can set their own password once they log in. Very typical for a website out there on the internet. So, it works very well like that.
The downside, of course, as you are probably reading into it, that you are creating your own password for your account and it’s one more password to track, to monitor, and to change on a regular basis. And the other big downside is, because we’re not tapping into your back-office active directory data store here, that this user, if somebody leaves the organization or something like that, we can’t just turn off the active directory account and get rid of their access here, so you’d have to have a step (a manual step) to go out to ArcGIS.com and delete or perhaps just disable that local user account within ArcGIS.com. So that’s the downside. It’s not truly an enterprise approach, but again the upsides in this case usually outweigh it which is: it’s really easy to set these up and you can get users access very quickly. So, local users, big plus.
Next, if you say “Hey, that’s absolutely not going to work with us and we still want to work with ArcGIS.com,” the second way to get out here is to actually put in something to do with your LDAP or your active directory authentication. Almost everybody has active directory these days, so we’re going to specifically hone in on active directory, but they support other LDAPs as well (Esri that is) and there is a lot more information online.
To do this is doable, but it’s a little bit tricky, so want to talk through some ins and outs there. So of course, active directories are always behind the firewall in your back-office. This has your users. Here at SSP we have a domain: ssp\ and I’m sperry and many other users throughout the organization. I want to use that account to get access to this third-party site, ArcGIS.com.
The key here, and this is not an area of expertise for me, I’ll be honest with you, but it’s an area I’ve learned a little bit about by working with some other good professionals in the area, is called ADFS, or Active Directory Federated Services. So, this is another piece; there’s a server in here, and I don’t know the details behind it all because that’s not my area, but they’re taking this active directory and they are exposing, through the firewall (represented here in red), your active directory ability to sign on. This can either be fed directly out to ArcGIS.com or you can create an actual site that is a log in site that you host, that allows the user to authenticate against active directory and essentially say “Hey, this is a valid, authenticated user” back to Esri ArcGIS Online. But the key here, either way, is that we need to be able to talk to ADFS from ArcGIS.com, and ADFS is brokering the data to active directory.
When we talk about the details here, getting this set up is not trivial. I want to be honest about that. I’ve had really only one account that has gotten to the point where they have gotten this working. You get the ADFS endpoints exposed to the internet. That’s the first key point. Then when you get here, you are actually taking a series of metadata files and loading in both directions.
Your ADFS will either provide a URL, that’s an internet URL, and/or a metadata XML file that we can take and load into ArcGIS.com that says “For authentication, we are going to go against this endpoint with the active directory.” Then, also, ArcGIS.com then, the opposite direction, generates a URL and/or an XML metadata file that we have to tell ADFS about. That allows AD to say “OK, we trust ArcGIS.com with this authentication information.”
Within configuring some specific information going back and forth, like the actual name of the user, we’re putting in there usually the email address, etc., a few other attributes that we pass from active directory back to ArcGIS.com. Now the mechanism by which this happens is something called SAML. I’m not going to go into the details of SAML, but you can Google that. It’s a security markup language and there’s a lot more information out there.
So pretty high tech, pretty cool if you can get this working. I just want you to understand that there’s some detailed challenges there, and if you don’t have a super strong active directory group within your organization there might be some challenges there to get that. So, these are the reasons that we’ve mostly stuck with local users as far as our authentication patterns for getting Esri ArcGIS Online set up very quickly.
Hopefully that makes sense. We are authenticated here. We come back in through the DMZ. We can get data. Everything works one way or the other there.
So, the question then, “So that’s Esri ArcGIS Online. What about Esri Portal for ArcGIS, and why is that different, or perhaps easier or a little more challenging.” So, Esri Portal for ArcGIS, you’ll notice, is a server instance that will live in the back-office. It could be on the same box as your ArcGIS for Server. It could be on its own dedicated box. Either way, it is an actual installation. Now, as a reminder, Esri Portal for ArcGIS is effectively bringing ArcGIS.com on premise. This side of the firewall; you own this.
The key here is that this box is already going to be registered with active directory. It will be an active directory server that already knows about active directory, so these are associated by default. Again, we can’t have ArcGIS.com serve this role behind the firewall because it’s out there, it’s on the other side. So, the simple fact that this is behind our firewall, on our infrastructure, makes this really easy.
We can actually put in a very simple JSON, which is just another technology, but there is a string that we can plug into Portal to allow it to talk to active directory, and it’s as simple as taking a service user on your active directory, plugging it in, and giving it read-only access to active directory. Voila, Portal can then access active directory natively.
So, now we’ve got Portal that has taken the place of ArcGIS.com, in this case, it natively and very easily will allow you to do authentication using active directory. So, that’s the big upside here. We don’t have to worry about exposing ADFS out to the internet, etc.
The big downside, of course is that we do have to install a lot of infrastructure for Portal. We have to support Portal and there’s the total cost of ownership of that, not just for the implementation, but again including support costs over a period of years.
So, there are some trade-offs. When people say, “What is the biggest difference you can call out between Esri ArcGIS Online and Portal?” my two key points I always talk about are authentication, the topic of this video, and then of course the finance related aspect of the money it takes to both stand it up and support it. Both are great options.
We’re now seeing more and more users that do both. They will use a combination of Esri ArcGIS Online and Portal in the back-office. In either case, it’s going to provide you the tools that you need for today for exposing your maps to everyone in the organization. It’s also going to set utilities up for the future once we start moving towards the utility network, which will be focused on services based and hosted through either Esri ArcGIS Online or Portal.
Thanks for your time.