Connecting to Portal without user input credentials

1550
5
02-01-2021 06:50 AM
GeoSolver
New Contributor III

Are there any best practices for creating ArcGISPortal objects in C#/.NET in scenarios where the code needs to run independently without user input?

In this scenario, I am developing a console app that will be called by Task Scheduler, so a user will not be present to input their username and password to establish the connection to ArcGIS Online.  It boils down to these two lines of code.

 

 

TokenCredential userCredentials = await AuthenticationManager.Current.GenerateCredentialAsync(serviceUri, username, password);

 

 

 Then the token credential is passed to the method that creates the portal object.

 

 

portal = await ArcGISPortal.CreateAsync(new Uri(ServiceUrl), userCredentials);

 

 

In order to make this approach work in our scenario I would have to include the username and password in the source code.  It could be obfuscated through encrypting/decrypting methods, or stored in settings, but neither of those approaches are secure.

In arcpy a script can leverage the active portal on the host machine.  I believe it simply uses the last portal that ArcGIS Pro loggged into.  This approach has worked well for us with scripts that are called by Task Scheduler.  But in this case we aren't using arcpy.  Is there a way with the C# .NET ArcGIS runtime to use an active portal?  If not, what is the best practice in this scenario to keep user credential confidential?

0 Kudos
5 Replies
JoeHershman
MVP Regular Contributor

I don't know that you could access the last portal used by ArcGIS Pro.  And even if you could this would be dependent on someone having logged in recently enough that the token has not expired.

Nor sure why you don't want to encrypt a password.  Seems on an internal application that would be secure enough.  Not sure what other ways ArcGIS Enterprise is used within your organization, but IWA is an option if your users only access through a Windows domain.  Using IWA would be my suggested approach if that could work within your organization

Just an FYI:  While I am certainly not going to tell anyone and I may be wrong, but my understanding is that Runtime is not licensed to run internally on a server.

Thanks,
-Joe
0 Kudos
GeoSolver
New Contributor III

@JoeHershman wrote:

Just an FYI:  While I am certainly not going to tell anyone and I may be wrong, but my understanding is that Runtime is not licensed to run internally on a server.


I'll try to confirm this.  If true then it seems like an arbitrary limitation.  What are .NET developers supposed to use?  ArcObjects?  

0 Kudos
JoeHershman
MVP Regular Contributor

We use the rest API directly for server side applications that don't require a UI

Thanks,
-Joe
0 Kudos
KirkKuykendall1
Occasional Contributor III

Did you try OAuthClientCredentials for  TokenAuthenticationType  ?

"OAuth access token generated after an authentication on behalf of an application. This authentication uses the OAuth client credentials workflow and doesn't need any UI (but needs the ClientSecret)."

 

0 Kudos
GeoSolver
New Contributor III

@KirkKuykendall1 wrote:

Did you try OAuthClientCredentials for  TokenAuthenticationType  ?

"OAuth access token generated after an authentication on behalf of an application. This authentication uses the OAuth client credentials workflow and doesn't need any UI (but needs the ClientSecret)."

 


I've done this with the JavaScript API but not using .NET.  I'll look into it.

0 Kudos