Question

How can I store securely an API token which is used for authentication within a HTTPCaller?

  • 9 January 2023
  • 6 replies
  • 71 views

Hi everyone,

 

I want to use an API via the HTTPCaller. The authentication is done via an API token. Is there a way to securely store the API token like the username / password combination within a Web Connection?

 

We place our created FME Workspaces in a git repo and don't want to put any authentication data there .

 

Thanks for your answers in advance. :-)

Peter


6 replies

Userlevel 4

A method that is fairly often used, is to store secrets or credentials in the OS environment. You can then easily retrieve it into your workspace using the EnvironmentVariableFetcher. It should work equally well under both FME Desktop and Server, and supported by Windows, Linux and macOS.

Hi David,

 

thanks for the quick response. 👍 😀

 

That's an interesting approach. But everyone with access to the host has direct access to this environment variables... at least if the token is stored in global variables. If I put the variable in the user context, I have to determine the user for the process which is running the FME Server. Right?

 

Do You have any additional suggestions to improve the security?

 

Greetings,

Peter

 

Userlevel 4

Hi David,

 

thanks for the quick response. 👍 😀

 

That's an interesting approach. But everyone with access to the host has direct access to this environment variables... at least if the token is stored in global variables. If I put the variable in the user context, I have to determine the user for the process which is running the FME Server. Right?

 

Do You have any additional suggestions to improve the security?

 

Greetings,

Peter

 

Correct, you would usually only set the environment variable in the user context. If you are already running the FME Server services with a domain user, it's fairly easy to set the environment variables only for this user.

An alternative would be to put the user credentials in either a configuration file (secured with file system user access) or in a database.

Userlevel 3
Badge +17

Adding a lot of OS environment variables for storing Tokens outside the FME Workbench would not be my choice.

 

It would be nice if you had more flexibility with the WebConnections solutions, but this is pretty rigid.

 

I think I would create a customTransformer with a ParameterFetcher and a Password Parameter. When you save the customTransformer FME will ask to password secure the FME Workbench.

 

In GIT you will see a fme_decrypt( blablabla ) in your git repository and not the token information.

 

I think it would be secure if you save the customTransformer outside of your GIT environment. Because I could imagine that with enough knowledge you could decrypt just like FME decrypts the password that is needed to extract the contents of the customTransformer.

 

But I think this would also be true for the WebConnections. These will live somewhere on your desktop and on your server so it would be possible to find them if you have access to the machine.

 

In your case:

If you don't want anyone with access to the host to have access to the Token, there is only one solution. Store the token with the user that runs the process. Because if the user has access to the host and the host has access to the token you have a problem. But in all cases, keep in mind, if FME needs the token and the user can edit the FME workbench and run it on the same machine, it could edit the FME workbench to reveal the Token.

 

 

 

 

 

 

 

 

 

 

Userlevel 4

It seems FME Server 2023.0 will get a Configuration Store that might be a good solution for securely storing tokens and other sensitive information. Unfortunately I do not have much information about this at the moment (it might be based on https://community.safe.com/s/bridea/a0r4Q00000Hbs8TQAR/serverwide-global-keys-for-fme-server ?), but I think it should be worth looking into when it's released.

Thanks for all the detailed information and additional outlook what might be coming. 🙏 😀

Reply