How can I have Google Cloud Security Scanner log into my app? - security

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.

Related

Unable to setup Custom Scan using Web Security Centre Google Account Authentication in GCP

I am trying to setup Web Security Centre for my Google AppEngine App.
I tried using Google as well as Non-Google Account for Authentication where I provided Username and Password but it errors out saying
Could not sign in using the provided username and password
I tried below things:
Tried creating a test account vikash-security#gmail.com (in compliant with google naming convention) in my gmail and using the same for authentication. (this user had same domain name as my company's)
Created a test user with different domain name and used it for the authentication.
Both the above users have access to my Google App.
Both of the way did not work and throws the same error. Can anyone help me out with the same?
Google enforces a real name policy on G+ accounts. Your test account may be blocked from G+ if the name does not look real. at [1]. It will only work if the Google account you provided should have been G+ verified (with proper G+ setup), but still need to retry after the first failed attempt and it eventually will work.
There are few issues related to this and if this is a bug it will be resolved soon.
I raised this concern with the Google support team and got to know that there was issue from their end and they got this fixed and now my web security custom scan is working with non-google authentication.

Google API Authentication: are there alternatives to service account keys?

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?

DialogFlow Authenticating with external application/API

We are prototyping in dialogflow which is going well but I have what is more of a strategic question. Our app will interact with APIs in a third party system that requires user/password credentials, I am wondering if anyone can recommend an appropriate approach.
For example when I start the app in Google Assistant it knows who I am from my google account, this account however has no authorization for the target system - it needs an ID / password. I can prompt the user for these and they can type/say the values with which we can connect but this prompts more questions:
Is this secure? Clearly speaking my password isn't a great plan.
If this approach is reasonable is there a way to save my credentials within the app so that I don't have to enter them next time?
Are there other approaches to remote authentication you'd recommend? I have searched around but so far without any success.
Any tips would be much appreciated.
Chris.
Google provides build in authentication options for Google Assistant. Have a look at the documentation. If you wish to connect your Google Assistant app to your own login you want to have a look at the 0Auth or Google Sign-in + OAuth options. Depending on your requirements, one might be a better fit.
Accountlinking is a build in solution, if you implement this you will have done it in a secure way and it is integrated with the users Google Account, so when they come back into your app they won't have to enter any credentials again.

Xamarin Forms OAuth2 Microsoft/Google authentication

I'm building an app that should be able to send emails. I'm using OAuth2 to verify the user, and I've looked at the Xamarin Forms Sample which works great with gmail after setup.
However it doesn't work with my Microsoft account.
I've created a cliendId and all that stuff on Microsoft. Do I have to have a Azure AD as well?
I'm calling the authentication with:
new OAuth2Authenticator(
"myClientId",
"User.Read",
new Uri("https://login.live.com/oauth20_authorize.srf?client_id=myid&scope=user.read&response_type=token&redirect_uri=https://login.live.com/oauth20_desktop.srf"),
new Uri("myRedirectUri"),
null,
true);
But am reaching a screen saying: We cannot perform your request.
Microsoft-accounts is having technical issues right now. Try again later.
Have looked at this sample, where the author uses Google and Microsoft accounts in similar ways.
If I'm instead using this sample it works with the original setup, but not if I change to my own clientId and redirectUrl. Is this since I don't have any Azure account?
Would not like to pay to get it, and since the first approach works fine with my gmail I would love if it could work with Microsoft as well.
/Oliver
Have you tried the microsoftonline.com endpoints instead? I've also implemented this using Xamarin.Auth and could get it working that way.
AuthorizeUrl: https://login.microsoftonline.com/common/oauth2/v2.0/authorize
AccessTokenUrl: https://login.microsoftonline.com/common/oauth2/v2.0/token
"common" is the {tenant} which you can replace with "consumers" if you only wanna allow personal accounts.
An alternative to coding it yourself, is to use a 3rd party library to handle authentication.
CloudRail have SDKs for Xamarin, with build-in integrations for social login/authentication, and also for email sending, which you mention.

Validate user in Azure Active Directory; Not using SSO but using username and password

With the recent release of Azure AD, we would like to use Azure AD for our web application authentication, but we do not want to use SSO. We do not want users to be redirected to the Microsoft Account login screen, and then come back. We want to supply them with the login credential screen where we capture their username and password, and then we want to programatically do the authentication against Azure AD, and get back the claims identity.
The problem I have is that I cannot see how I can do that using the Graph API, and all the examples that look like it might work, only works on the previous [0.8] release. There is such a mix of examples that is supposed to work, but they don't simply because of the new release.
Can anyone tell me if this is even possible, and maybe point me in the direction of how to do it please.
I do not want to use ACS.
What you are asking for is not technically possible with Azure Active Directory today. That scenario could possibly be supported in the future, so check back from time to time.
We really encourage developers to rely on the in browser sign in experience. The reason is that because the browser allows the server to define the experience, it allows for much greater flexibility with respect to the kinds of credentials that can be employed. For instance, if you code your app to use only username and password, then it may need to be updated in order to take advantage of two factor authentication. If you rely on the browser based experience then your app can be totally agnostic to whether 2FA is being employed, or any other kind of authentication dance.
We recognize that there are some scenarios where this is not ideal or even practical and are looking at solutions to those scenarios that may be supported in the future.

Resources