Unfamiliar with handling secure data but now I've began working in azure, specifically with a dynamics instance and logic apps. The webhook needs to give the external api secure data such as ssn. What's the best way to go about sending secure data like this over network? Oauth2 is implemented but is there something else I can implement so we are not directly sending the ssn?
Always using SSL (HTTPS) is a secure way to send data over the wire. I believe a little more added security would be to use Certificate and Public Key Pinning if possible.
Also, another way to secure sensitive data would be to first store it in Azure Key Vault and share the reference to that secret in your webhook call to the Logic App.
The Logic App would then acquire the secret from Azure Key Vault using Managed Identity.
Related
Good day,
I have a question about the following scenario:
A client opens a web application in the browser. In the web application, secrets are retrieved from an Azure Key Vault using Javascript. Then, with these secrets a connection to another Azure service is established to retreive data.
Question 1: Azure Key Vault only secures the transfer of the secrets. The client could see / reverse engineer the secrets in the web browser after retrieval and see them in plain?
=> Is this correct and is this still secure?
Question 2: With these secrets the client can authenticate to the other service.
=> Is it possible that the authentication / use of the secrets is only allowed by the web app? So even if the user knows the secrets, he should not be able to use them in another application.
Question 1: Azure Key Vault only secures the transfer of the secrets.
The client could see / reverse engineer the secrets in the web browser
after retrieval and see them in plain?
=> Is this correct and is this still secure?
That is correct.
If you load the secrets to front-end, the user can take the plain text.
Question 2: With these secrets the client can authenticate to the
other service.
=> Is it possible that the authentication / use of the secrets is only allowed by the web app? So even if the user knows the secrets, he
should not be able to use them in another application.
I would say that is impossible.
Your app is a front-end public client application and thus cannot authenticate itself, meaning only the user can be authenticated.
I recommend that you do not load secrets to front-end if there is any possibility of their abuse should a user get them.
Instead you will either need a back-end or a different approach where you instead authenticate as the user to the service you are trying to access.
But that depends on the service, so please let me know what service you are trying to connect to.
We want to call a REST API endpoint of a SaaS application. i.e. system to system interaction.
We are using Azure Data Factory to call and we could see that ADF support(Web client activity) client certificate authentication.
We have the certificate with us. Added the certificate to AKV, configured ADF to use the certificate.
Question:
Do we need an app registration to be able to use?
What details do we need to send to the SaaS vendor so that they can recognize that our call is a legit call?
Are there any other steps in the process?
From the way you're describing this issue, it sounds like the SaaS isn't an application that is protected using Azure AD. In that case, the SaaS determines what credentials are suitable - likely a username and client certificate. I can't think of a reason for you to need to create an app registration. All of this said - you need to talk to the vendor to ask them what credentials are necessary for access.
I am new to Azure API Management and will be happy to receive suggestion and advise on my implementation.
I am developing a B2B Api Channel for 3rd parties to call my services via the API Management (APIM) Gateway. On the APIM developers portal I can onboard new clients and generate API key. My struggle is how best to figure out at the underlying services who is calling?
I have considered add the API Key generated in the APIM to a database which the underlying service will call to authenticate, however, the implementation will be manual and will not be in sync when the 3rd party client goes to APIM and regenerate a new API key.
What I want is a solution that auto syncs authorization and authentication between APIM and the underlying services.
Since API keys can be replaced, you better rely on IDs to identify clients.
You can pass a client ID to a backend in a header: https://stackoverflow.com/a/42277313/2579733
Now how do you correlate APIM's client IDs with your backend's client IDs?
If there are only a few clients, you can probably update that association in your backend's database manually. If you can use the clients's email to connect the APIM client and your backend client, that's even easier (you're done).
If you will need to register many clients and the manual approach is not feasible... One way to do it is with Delegated Authentication:
Delegation allows you to use your existing website for handling developer sign in/sign up and subscription to products, as opposed to using the built-in functionality in the developer portal. It enables your website to own the user data and perform the validation of these steps in a custom way.
I never used it but it seems you can transfer the responsibility of creating new clients to a backend service (developed by you).
This way you have access to client emails, you generate IDs and can store the ID relationship in the backend as necessary.
I have a scenario where I have to let external systems have access to one of our internal API's.
The security team want the externals to use client certificates as the preferred authentication method, so that basically leaves us two options:
Use direct client certificate authentication. It will give us the most control, but that will leave all the certificate handling and validation in our hands, and I'd rather not do that if I have a choice. Besides - direct client certification auth does not play well with our existing authentication methods on that API. If you turn on client certificates on the App Service, you will require a certificate on every request (and most requests on that API use cookies)
Add key credentials to the Azure AD app. We'd rather not give access directly to the app the API is registered on, so we register a OUR-APP-EXTERNAL and set up a trust relationship between the two. So the client authenticates with a certificate to the "external app", gets a bearer token and use that on our API. I'd prefer to use this solution, and it seems to play nicely with everything else.
So far so good - but I'm worrying about scaling this. We have to separate the external clients somehow (each client will in effect be different systems in different companies). One strategy is to create one AD-app per external system (OUR-APP-EXTERNAL-SYSTEM-A), but it seems cumbersome and somewhat spammy. One quick and easy solution would be to add some metadata from the client's authentication certificate (where we could just set what system this cert is issued to during creation), and add that to the bearer token.
Is this possible? Or are there other ways to handle "multi tenant" external clients?
Thanks
Consider an option of using Azure API Management for your scenario. API Management provides the capability to secure access to APIs (i.e., client to API Management) using client certificates. Currently, you can check the thumbprint of a client certificate against a desired value. You can also check the thumbprint against existing certificates uploaded to API Management.
Follow this guide - How to secure APIs using client certificate authentication in API Management
Also you can create multiple Azure AD Application for different clients and provide provide required roles to each of these Azure AD application to Azure AD Application registered to secure Internal API.
Follow this guide for this approach - Protect an API by using OAuth 2.0 with Azure Active Directory and API Management
I am creating an application and native apps which shall access a bunch of RestFul Webservices. We are already using HTTPS to secure the API, but wanted to understand if we still need something like an API Key or OAuth Key to authenticate the data
Encryption and Authentication are two separate things. Encryption merely prevents outside parties from snooping the transmitted data. You need Authentication if you want to control who has access to which resources using the API.