I'm seeking your advice to piece together a mechanism that would facilitate authentication to Dialogflow ES and CX to allow running experiments on multiple agents (projects) from our workbench application in a smooth and error-proof manner. The workbench is an internal tool written in TypeScript (using the dialogflow RPC node module) running outside of GCP. Our users analyze the results of sending the same inputs (utterances) to multiple agents, usually going back and forth between them in the course of their work.
With proper IAM configuration, we have been able to detect intents successfully by doing a gcloud auth application-default login, however we haven't found a way to update the quota project programmatically or to specify the quota project through the google.cloud.dialogflow library, so we haven't been able to fix the "switch easily between projects" part. It looks like tampering with the quota_project_id property in application_default_credentials.json once authenticated is the way to go (gcloud auth application-default set-quota-project <project>) but we would have preferred doing this programmatically.
Using service account keys (JSON) works as expected and that's what we have been doing so far, that's also what we do in our CI/CD pipeline and in our agents running in production. But we aim at reducing the amount of service account credentials file that we share with individuals. Ideally, speech/data scientists would use their own end-user credentials to perform experiments.
We are looking for alternatives so that users would authenticate once with gcloud auth application-default login and the workbench would handle the rest behind the scenes, using only, as additional argument, the project-id against which the experiment must be run. This would eliminate the need to pause the experiment to update the quota project (using set-quota-project), or to update the GOOGLE_APPLICATION_CREDENTIALS variable when using service account keys.
Another thing we tried was Service Account Impersonation, unfortunately this does not seem supported by the google.cloud.dialogflow library, so even though we were able to successfully submit requests (with Curl/Postman) to the Dialogflow RESTful API using impersonation, we haven’t been able to leverage this mechanism in our code.
Has anyone been able to overcome a similar challenge? Is there any other authentication mechanism that could help us achieve this goal?
Related
I am creating a React SPA that will connect to a dotnet Web API backend. I want to use b2c to handle auth.
I want to have endpoints in the API protected based off the claims in the b2c token, also want to check claims in the frontend aswell.
Following along with token enrichment docs - https://learn.microsoft.com/en-us/azure/active-directory-b2c/add-api-connector-token-enrichment?pivots=b2c-user-flow
I can use an API connector to enrich the token with additional claims before it is sent back to the client, presumably with a function to provide values from my database in a users table.
If my database will also be hosted in azure, how would I develop and test this locally?
Is this flow the best way to achieve the desired behaviour? If not what are alternatives?
I've done two methods when testing 'locally'.
Create an Azure Function echo API service in 'cold' mode to reduce cost. This will allow you to easily ping it and it will ping you back the content. You can also add test cases pretty easily. This isn't really 'local' but, it's low cost and allows you to collaborate with multiple team members.
Use a free web service like Post Test Server. With a couple clicks you are off and testing with lower effort. The problem with this solution is it is public so do not use any proprietary or confidential information. I've created very complex dot notation in body of REST-API technical profile via custom policies and this was effective testing data formatting and internal business logic.
Last option could be creating a web service locally on your device - I haven't done this end-to-end but you would follow this same process as hosting an application locally with localhost.
You can deploy an Azure database solely for development purposes. Or you can just mock the API response so that you can do some basic e2e testing: SPA -> B2C -> API.
So my project has got a two asp.net projects. One is for showing date(User Interface) and the another one is API(for background processes like login, database calls and etc.). Right now my app has Username and Password feature to login. I have setup a startup class in my API which authenticates the user and pass the user token. Now I want to add a feature to login through Azure portal.
Can anyone suggest me a good practice in this situation? Like I don't want to change my code and just add a feature. Should I make changes in API or Web or Both? Meanwhile I was reading about expose api in app registration. Will it be appropriate to use it just for login purposes?
Azure AD supports OAuth2, OIDC and SAML. See more information here. It is probably best to introduce the mechanism through the API first, since it would apply to the frontend as well (though slight modifications may be required there as well).
I have decided to try to manage releases of one of my apps on GitHub as with GitHub Actions, I can build on Mac, Linux and Windows and automatically push the artifacts to the GitHub Releases page, where anyone can go and download the app from.
However, I want my app to self-update, so the app itself also needs to be able to query what's the latest version in the repo releases, and then download the relevant asset for the user's OS... which I thought would be a non-issue... however, there's no way to access the GitHub API v4 without either an OAuth app or a personal access token.
I don't want an OAuth app because the users of my app are absolutely not expected to be GitHub customers. So I tried to use a personal access token whose only scope was access to public release assets (which, again, is a public resource anyone can go and manually download).
As this token can't do anything you or anyone else can't do manually, even without a GitHub account, I thought it would be fine to put the token in the source code of my application, but GitHub revokes the token when it detects it on a commit.
Is there a good way to work around this? Should I put the token in a GitHub secret and then try to replace a placeholder with it during compilation?? I wanted to avoid that as that makes it hard for me to test the app locally, and also, it doesn't solve anything as anyone can easily decompile the app and find the token there (supposing GitHub would not detect the secret is present in the "processed" sources during compilation).
Any suggestions would be appreciated.
however, there's no way to access the GitHub API v4 without either an OAuth app or a personal access token.
The GitHub API v3 does support unauthenticated calls, but it's limited to 60 requests/hr per IP address: https://developer.github.com/v3/#rate-limiting
For unauthenticated requests, the rate limit allows for up to 60 requests per hour. Unauthenticated requests are associated with the originating IP address, and not the user making requests.
The Latest Release API docs will show you what information is returned, but I suspect you'll need to make a secondary call to List Assets for a release to know the files the client needs to download.
If that's not satisfactory (e.g. you know you'll have many clients try to update using the same IP address), and you'd like to ensure they aren't being rate-limited, read on for a different approach.
Is there a good way to work around this?
How I would tackle this is by deploying a small web service (e.g. Heroku dyno) that your app can will call without needing authentication, which then performs the actual lookup for the latest version (using a PAT that gets embedded as an environment variable) and returns a simple JSON response that the client will understand.
Benefits:
no token embedded in client
development mode can even call same service
add logic to service that the client would perform to simplify your app
e.g. call /latest/beta or /latest/stable to indicate it's looking for a specific channel
perform both API calls and return the assets that the client needs
can update token in service whenever necessary (e.g. to refresh token) without changing client
can cache response to reduce risk of being rate-limited
Downsides:
more moving parts to manage in your overall architecture
need to worry about uptime of the service if there are lots of clients connecting
this can be offset by making the client resilient to failure cases
I'm making an iOS/Android app using Xamarin (not Xamarin.Forms, just regular Xamarin). I'm using the shared library set up rather than PCL. I want my app to call an Azure function but I'm unsure of the safest/best way to handle this. I have it set to "Function" for the "Authorization level". The test URL includes the "?code=..." portion in it. I was under the impression that if I put that in my C# code with the "code" value exposed that it was considered a bad idea from a security perspective.
I'm lost as to the safest/best way to deal with this. I've read that setting it in app.config is also a bad idea. I found some references for a web app that suggest using the connection strings that are available in the azure portal, but since this isn't a web app, I'm unsure of how I'd actually retrieve those values in my code (or if that's even possible).
So how would you suggest I handle setting the value for "code" so that I can call my function and avoid a security problem?
UPDATE: Providing more info as per request:
I'm using MSAL to authenticate my users with a B2C active directory. I already have that part working and have received a token authenticating the user.
I also just now enabled authentication in my functions.
I was under the impression that to call my function from my mobile client I had to make a new HttpRequestMessage. I'm unsure of then what I'd place in it to pass my token along.
Just to make sure I understand, your concern is about embedding secrets (the ?code=XXX value) in your iOS/Android app, correct? If so, yes, this is generally considered bad security practice. It's best to assume that anyone who can download your app will have the ability to discover these secrets and use them any way they want.
The recommended way to authenticate with a backend service, such as Azure Functions, from a mobile device is to use interactive authentication - i.e. some kind of OAuth flow. You can build it yourself, or you can use the built-in functionality of Azure Functions and Azure App Service to help you (Azure Functions is built on top of App Service). Here is a resource which might be useful:
https://learn.microsoft.com/en-us/azure/app-service/app-service-authentication-overview
https://contos.io/working-with-identity-in-an-azure-function-1a981e10b900#.vcjit3ntw
The API Key (code) is indeed not meant to be used by clients you distribute externally, so it shouldn't be used by your mobile app.
The most straight forward option here would be to use the built in App Service Authentication features with Azure Functions and implement an authentication flow in your app, which would allow you to securely authenticate the user.
Sharing more information about your scenario may help identify alternatives.
I ran Google Cloud Security Scanner against my Google App Engine app. I asked it to authenticate against a "Non-Google Account" -- in other words, user-name/password fields in my webapp. However, I get back the message "Could not sign in using the provided username and password" each time.
(I tried it several times, specifying different user-agents and credentials and against two variants of my login page; and of course confirming that the credentials work when typed in manually. I have the necessary Editor-level permissions on the Google Cloud project.)
What do I need to do to get the Scanner to authenticate?
Here's what the docs say about Non-Google account authentication:
Note that support for login forms is still in development, and may not
work out-of-the-box with your system. If you have confirmed your test
account is able to login manually, but not in Cloud Security Scanner,
use the feedback option within the tools to request support.
One possible workaround is to create a simplified alternative login form for the purposes of using the scanner if it's unable to work with the current one.