Best Practices for Connecting to Enterprise Portal in R?

[KevinBoes2]

I work in an organization with many R users and comparatively few ArcGIS users. We manage our GIS data within an enterprise, and we have an enterprise agreement to manage licensing. We would like to take advantage of the arcgis meta-package to give our R users access to data and locator services hosted in our enterprise portal, and we're hoping to avoid relying on authentication through ArcGIS Pro credentials since most of the R users don't have that software or license.

I've been following the "Introduction to the R-ArcGIS Bridge" course offered by Esri in their training catalog, and it outlines granting access to an enterprise portal using an OAuth 2.0 application. While this process worked for me, I am having trouble figuring out how to help other users use this application to connect to our enterprise within their scripts. My impression is that these OAuth 2.0 application items are designed to be used for web applications rather than R scripts or notebooks which are stored locally. 

I would like to facilitate a process where our R users make use of a user authentication process to connect to our enterprise portal using their own login credentials. Should I be using an OAuth 2.0 application for this process, or is there a better practice for granting access to an enterprise portal in R for multiple users?

[EricaNova]

@KevinBoes2 , I'm going to PM you - I've been struggling to get this to work in a web application (Shiny) and would really appreciate it if you could share a working demo. My goal is to allow staff to connect to their accounts in a Shiny application. Do you think your workflow would be appropriate for this purpose? I've been back and forth with Josiah Parry (package author) but still not having any luck.

[KevinBoes2]

After doing some digging through documentation, I found that the function I'm using to authenticate with our portal, arcgisutils::auth_code(), only requires an ARCGIS_CLIENT value and ARCGIS_HOST url to be set in the R environment to successfully authenticate the user's portal credentials. If I'm interpreting Esri's OAuth 2.0 documentation correctly, the Client ID that populates this ARCGIS_CLIENT value is essentially an identifier for the auth_code() function to use when locating the authenticator app within the portal. If so, it seems like I can provide this Client ID and our portal url to users for them to include in their R environment with minimal risk of releasing sensitive information about the authenticator or items within our portal that are not shared with their user.

Are there any security concerns with this approach that I might be missing?

[JosiahParry]

Hi Kevin, I would recommend each developer create their own API keys and store them in the environment variable `ARCGIS_API_KEY={the api key here}` in their own `.Renviron` file. This way each user's API key is scoped to their permissions. 

The OAuth 2.0 story has changed a lot in the recent months and I am unsure how this will work for us in the future. I am actively trying to work internally with the developer team to see how we can harness this. For the time being, I think an API key is the most practical approach.

[KevinBoes2]

I appreciate this recommendation, but I want to avoid a situation where each R user has to create their own API key. I wouldn't call our R users developers (in the sense of creating applications within an R environment) but rather as data consumers within R. As a result, these R users currently have viewer logins for our portal. Having them create their own API key would require them to have creator logins, which would carry a financial cost. Since these users are just using the portal connection to view data and use it in personal R scripts, it feels like assigning them user roles for creating portal items is beyond what they should need.

While testing this workflow, I shared the clientID for the authenticator app with another user with a creator login and another user with a viewer login. When they used the auth_code() function, the token they generated had their respective user information rather than mine. This appears to adhere to a user authentication model rather than an API key or App authentication model.

It's good to know that there may be future changes to how OAuth 2.0 authentication will work in ArcGIS.

[EricaNova]

@KevinBoes2 , actually, a developer account is free. I made my free developer account associated with my home email (it should not be used with the member's email already associate with an organization AGOL account) , shared my group's content to that account, made my API key, and was good to go. Feel free to message me privately for more details if that sounds like it could work for you!