Skip to main content

Hi FME Community!


Does anyone know how to create a web service in FME form to connect to ArcGIS Portal?
i see this article (https://support.safe.com/hc/en-us/articles/25407635174285-Web-Connections-and-FME#h_01J0S3JP9A7W1TX5B2GG56ZX8S) but could not figure how to properly fill all the parameters to get it working. my goal is to create a token based web connection to authenticate requests to endpoints stored in ArcGIS portal.

Thanks in advance!

Have you looked through this article?

https://support.safe.com/hc/en-us/articles/25407772142733-How-to-Create-an-ArcGIS-Enterprise-Portal-Web-Connection-OAuth-2-0


@hkingsbury Yes I have but that article is about oauth 2 connection and my question is about token based web service


I use a token-based setup to run processes on this community’s api. Having generated a token, I just use the HTTPCaller with a line in the Headers that is Authorization: Bearer @Value(APIToken).

Obviously it’s not the same as creating and using a web service/web connection, but it’s just as simple to use.

How would you create a token? Try the new EsriPortalTokenGetter transformer that @bruceharold just published.

https://hub.safe.com/publishers/bruceharold/transformers/esriportaltokengetter


Hi,

Can you allude a bit more about the endpoint you are trying to hit (e.g. a FeatureServer Url or a Portal Item) and how? The reason I ask is that the token for Portal vs Server differs and depending on exactly what you are trying to do, you may be able to select you oauth2 webconnection as the authorization without needing to expose the token to the workspace.

There certainly is an answer, but just need to understand your use case.

 

As Mark alludes to, there are plenty of transformers on the hub to get the token by putting username/password. If there is enough demand, I might combine a couple of process I already have to get the token from the token from portal/server from an existing webconnection (so not to expose passwords in workspace)

 

Cheers,

Todd

 

 

 

 


OAuth2 is a process of authentication that then generates a token for FME to use to access secured services.It also provides methods of renewing that token once it expires.

Portal access tokens only last for 120 minutes by default - https://enterprise.arcgis.com/en/portal/latest/administer/windows/specify-the-default-token-expiration-time.htm

If you’re wanting to connect to Portal, Oauth2 is the recommended approach as that will generate fresh tokens when calls are made to the service.

OAuth2 will also be able to utilise SAML and other external identity providers that the Portal instance may be using.

If you must not use OAuth2 you can use the generate token operation, i’m not sure how well this will work as a web connection - https://developers.arcgis.com/rest/services-reference/enterprise/generate-token/


 @todd_davis  Tnx

I am trying to hit a ArcGIS Portal hosted feature service using http caller. in that http caller i need to use web connection object made from token based web service.

Primary reason i wanted to avoid using web connection that authenticate using oauth is because the issue of expiry pf refresh token. not sure who but one of the safer also confirmed that when using oauth the refresh token wont be updated if that oauth based connection is not used for more than 2 weeks. and that issue has cause workspaces to fail here in our end

Esri also recommend to use token based connection for api interaction.

I dont know how well token based web connection will do the job either but wanted to test.

i’d love to see example on how I have to fill this parameters on the screenshot below to create token based web connection for ArcGIS Portal. the example on the knowledge base is for yelp only

 

configure token based web service

 


@todd_davis 
to be clear i have success in using this method (https://developers.arcgis.com/rest/services-reference/enterprise/generate-token/) to generate token in http caller and it works fine.

but i don't want to pass the user name and password with the http request to generate the token. however bake the creds in the token based web service  and create a web connection out of that as web connections are encrypted


Cool...so you know the refresh/access token details and how that works. And yeah, I too don’t like putting the username/password into a transformer either and the Oauth2 webconnection doesn’t hold the credentials, which is better for security. But as you mention the refresh token will expire after two weeks if not renewed (A process using the connection is not run)

 

When you authenticate via oauth2 in a webconnection, it is creating a refresh token and access token which is stored. But there is no automatic refreshing of these details until a process is run. For some of our clients that have a non-default refresh token like 8 hours, I built a process that performs the exchange of the refresh token in FME with as little calls as possible, but this can also be achieved, by undertaken a simple http call to an authenticated endpoint via FME (there are more calls involved, but it will update your refresh/access token) and avoid the need to reauthenticate.

 

In reality you have to run a process to ensure that refresh does not die, to get away from providing your username/password to a token service which then authenticates each time.

 


100 % @todd_davis we actually have workspace that consume resource that does not require authentication from ArcGIS portal and it runs nightly. i see that can be a good candidate to keep the oauth going as you have suggested.

i still see a value in creating a token based web service/connection for the ease of sharing with other users. I look forward to seeing example of how that can be set up
 


You can always create a token based web service in FME and share that. But personally, I always prefer to share an Oauth2 connection that users can’t get to the authentication details.

 

Not sure if you do this already, but depending on your user-base and how that is setup, if you have a centralised connection location, you can share connections across all users (Public meaning all users with access to that connection database or keep them private to yourself). Also helps ensure that there is more chance that the Oauth2 connections will be used within the default timelines.

Here is a example (reminds me that I need to tidy this up). In this case many of the public items here have been created by our other staff, but I can still use them.

 


Reply