When is Knime going to support external account as an authentication type within the Google authenticator? For security reasons that is likely the way most enterprise companies are leaning and currently it only appears to support service accounts or interactive mode (which defeats the purpose of automating it). We’re using WIF and I have a python script that will authenticate, but as soon as I attempt to pass the token to the Google auth node there is no support for external account so it fails. The only work around is to inject it into api requests, but that results in more work when all that is needed is some basic json support for external accounts.
Bueller…?, Bueller…?, Bueller…?
Beetlejuice, Beetlejuice, Beetlejuice…
Hi @kevinnay -
Sorry for the delayed response here. Let me ask internally and see what I can find out.
3 Likes
Appreciate it, thanks.
Hello @kevinnay ,
I have created a feature request for this (internal number AP-24124). However I can not tell you when this will be available.
The suggested solution is to use a service accounts for automated workflow execution. In addition, if you have the KNIME Hub with Secret Store you could use interactive logins for scheduled workflows. The secret store takes care of refreshing the access token as long as the refresh token is valid. The expiration time of the refresh token depends on the IDP and your corporate settings.
Bye
Tobias
1 Like
Wali Khan is working with our team(s) as part of a new hub implementation. Perhaps he can find a way to escalate since without it we are currently unable to connect to GCP, which is critical. I am still exploring work-arounds however.
There’s another problem on top of this. I was able to write something in python to authenticate WIF. Python can request a token and then needs to create an oidc_token.json with an expiration date added. That path then needs to be injected into the external_account json for the file attribute to the oidc token file. Where this becomes less secure is that this is all part of a component and the credentials configuration node is the only available node to hash the password. It only works with DB connector type nodes. So the only way this works is with a string configuration node that leaves the password exposed. Because Knime doesn’t support WIF that leaves us in a precarious place. Fortunately this will live on an internal production server, but it’s never a good practice to leave a password exposed. I understand why the credentials v type variable can’t be accessed by python because it would be very easy to decode stored passwords, but then how about an option to pass it downstream to python without the option to save so that it only works when scheduled for use and resets when the session expires. Seems like there should be a better way to do this.