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.
Related
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 would like to have your mind about an implementation. Thank you in advance for any suggestion :)
**Scenario**
I have a set of APIs. They are accessible via REST and protected by OAuth2. I have also a list of machines that needs to access them.
Question
On machine’s side, which is the best solution to access them? Should I implement a client certificate authentication or OAuth2 is a suitable solution?
**My doubts:**
In case of hundreds, thousands of machines, the certificate
management become too complex/costly?
Should I use a certificate for each machine or one certificate for more than one?
How can I deploy smartly the certificate to each machine?
I like the idea to have the mutual authentication, but I’m afraid is to heavy to maintain compared to the OAuth structure. I plan to use Microsoft Azure as cloud service.
Thanks!
I would say the important factors here are client identity and privilege:
You may have many client machines
But do they represent a single identity, eg a cluster?
And do they all have the same privilege?
By default I would aim for a solution where all client machines with the same privilege present the same credential / identity. The APIs can then authorize requests based on the client identity, provided in the access token.
The standard OAuth solution is Client Credentials flow, where clients each send a secret to the server.
If required (and supported by your Authorization Server) you can use a Mutual TLS form of Client Credentials, via the Client Assertion Profile. This usually boils down to a private key signature sent by the client, which is contained in a whitelist configured on the Authorization Server.
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.
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
Im writing a application where I can have multiple users login and store their password in windows credentials. I currently can successfully validate the user's login. My question is where is the proper place to store the permissions(ex access to a certain page). I have several databases but I don't think that's secure. Possibly encrypt the data in the table. Or maybe in the local settings
You should use the PasswordVault class in a UWP app for storing user credentials so the app can validate silently to your cloud service later. Here are details on how to use the API.
for non-password, non-sensitive data, you can store it in LocalStorage or RoamingStorage but that is not secure. The only secure location to store data is on your service. Look to use something cloud-based like Azure Mobile apps to store that kind of info.