Skip to main content

I have a use case where I want to store some client id and secret in my own company’s Azure keyvault.

Then I have a component which needs to use the client id and secret to authenticate against a 3rd party, so I can issue a GET call to get some data.

 

So I am thinking:

  1. Runtime server authenticate against keyvault
  2. Runtime server issue a “get secret” call to keyvault
  3. Keyvault sends back the secret
  4. Runtime server takes the secret and authenticate against 3rd party
  5. Runtime server issue a “get data” call to 3rd party
  6. 3rd party sends me back the actual data

 

What authentication methods from runtime server to keyvault are supported? I had a look at Azure keyvault’s documentation but I don’t think I understand it fully. https://learn.microsoft.com/en-us/azure/key-vault/general/authentication

 

Has anybody else done it? What’s your experience?

We found this in the docs:

Secret Management Services :: Ataccama ONE

But it looks like it’s only available in ONE, not in runtime server. And that this is v15. We are still on v14 right now.

Any chance this could be available in runtime server at some point?

 

( cc @Scott Barden @DannyRyan )

I drew a diagram hoping to make it clearer 

If someone from Ataccama has any comments it would be greatly appreciated!

Anyone has any ideas?

I suppose this actually extends beyond keyvault. What if when you need to do OAuth / any authentication method that goes beyond the simple username/password or client_id/client_secret, short of storing the creds in plain text in a json call step (or passing as parameters from .ewf or .sch, but it’ll still be on plain text in git project), what other options do I have?

(Cheekily tagging @AKislyakov - have you had to deal with something like this before?)

Hi @maykwok_hamilton,

The only supported authentication options for URL resources in Runtime Server are: Basic, Open ID Connect (with client/secret) and mTLS. The Secret Manager you mentioned is only applicable for One Gen2 sources.

Can’t speak for any authentication method, but for OAuth2 there is an option to send client_id/client_secret via Basic auth header.
So, your first call will look like following (these are connections ##2 and 3 on your diagram, but they go to Microsoft OAuth):

with an Url Resource configured like this

<url name="EntraApiToken" url="https://login.microsoftonline.com/<TENANT>/oauth2/v2.0/token">
    <authConfig user="<CLIENT_ID>" password="<CLIENT_SECRET>" class="com.ataccama.dqc.processor.bin.config.auth.BasicAuthConfig"/>
</url>

 

Ooh this is one combination I haven't tried. Going to give it a go today, thank you!

Yes, it worked! Thanks @AKislyakov !

Reply


Community Terms of Use & ConditionsCookie settings