I have recently installed freeradius with google authenticator. Freeradius integrated with cisco asa for 2-factor authentication of VPNs.
We have 2000 employees who want to use this service.
The problem is that to generate the code, each user must log in at least once and enter the code after scanning QR code. But the process is very difficult for 2000 people. Is there a solution to automate this process? Can we just send the QR code to each person and verification process happens on the first login?
Thanks everyone for your help
Related
Is it possible to integrate the DocuSign sdk in such a way so that the signing can be done completely in local environment where there is no internet connection that is without sending the document to DocuSign through API and storing the signed documents to local directly? I don't want to send the documents to be signed to the DocuSign cloud through API. If yes can anyone please share code example or helpful link?
DocuSign has an appliance - DSA. The appliance can be bought, installed, configured by you. You would have to first do all of that before you can make any API call without internet.
More information on the appliance and how you can try it out is here - https://developers.docusign.com/dsa-api
If your concern is that DocuSign might be able to see your documents, you can use the DocuSign Security appliance. That way your company has the encryption keys used with your documents.
If you don't want your documents to leave your building, use the DSA as Inbar mentions.
We are facing the below screen when trying to authenticate to Google. The app that we are trying to authenticate is used for internal development and we did not publish it to our users.
Any idea why this occurs?
We faced an Unverified App screen before (as below) but now the authentication is disabled.
OAuth Client Verification
Starting July 18, 2017, Google OAuth clients that request certain sensitive OAuth scopes will be subject to review by Google.
OAuth Client Verification
Starting July 18, 2017, Google OAuth clients that request certain sensitive OAuth scopes will be subject to review by Google.
Review is not required if you are only using it under the same account as created the project in Google Developer console. You can read more about this change in this help center article.
This change applies to Google OAuth web clients, including those used by all Apps Script projects. By verifying your app with Google, you can remove the unverified app screen from your authorization flow and give your users confidence that your app is non-malicious.
Once you have applied for verification it takes around a week and it should start working.
I found this thread some time ago when this happened to us in our development project on Google Cloud Platform.
You can use a project for development without verification. No problem on that. But there are some limitations (more information here and here). Basically, we reached the limit of 100 users accessing the application. It was strange because we were testing with few accounts (5-6) until we found that, if you uninstall and install the application again, it counts as a new user. We were testing incremental authorization, so we uninstalled/installed the application a lot of times and we reached the quota.
When you reach this limit, you will see the message "Sign in with Google temporarily disabled for this app" and only users from the organization where the project is hosted can access the application. So we couldn't make test with our accounts from a demo domain or our Gmail accounts.
The only solution available was to pass the OAuth verification form (even if you didn't want to publish the application), but there were problems to do it. For example, it was mandatory to remove http://localhost from valid OAuth URLs. And more problems related with development.
❗ But this has changed recently. I have accessed to OAuth credentials screen in Google Cloud Platform (APIs & Services > Credentials > OAuth consent screen) during this week and now the page it's different. Now you don't need to specify "Authorised JavaScript origins" and "Authorised redirect URIs", you just need to specify your scopes for Google APIs and the Authorised domains. Then, at the bottom of the page you will find the button "Submit Verification" and the process will start. You will also find some information on the right:
About the consent screen
The consent screen tells your users who is requesting access to their data and what kind of data you're asking to
access.
OAuth Developer Verification
To protect you and your users, your
consent screen may need to be verified by Google. Without
verification, your users will see an additional page indicating that
your app is not verified by Google.
Verification is required if
Your application type is public, and You
add a sensitive scope Verification may take several days to complete.
You will receive email updates as it's processed.
Saving without publishing
Even though your consent screen is
unpublished, you can still test your application with users with the
following limitations:
Sensitive scopes are limited to 100 grant requests before verification
is required
Users see an additional page indicating that your app is
not verified by Google.
To include "Authorised Javascript Origins" and Authorised redirect URIs" you need to go to APIs & Services > Credentials and there click on your OAuth 2.0 client ID. There will be a form where you can add them.
In our case it took 1 day to get a response from Google. In the email there were some instructions to pass the verification. We had to reply the email with a video uploaded on YouTube addressing the following points:
How does user sign-up on your app and grants access to the sensitive scopes requested in verification?
OAuth consent screen as seen by end users
How does your application use the requested scopes to provide services to developers?
A test account email and the password for us to test the user sign-up process and validate the project's functionality.
We recorded a video showing points 1, 2 and 3 and sent them a test account for number 4.
After 1 day, we got another response from Google confirming that our project had been verified.
So finally the problem was solved! 🙂
I hope this could help people in the same situation. It was really annoying for us.
I had to go into my Google Apps Script settings and turn on the "Google Apps Script API" setting. Then I tried again, and the script executed correctly without issue.
I had used the script a couple of weeks ago and it worked fine, so something must have happened between then and now that changed it... Not sure what caused that setting to switch.
Good day guys,
Please, I am working on a project that requires setting up Google Adwords account in order to use the API. I am using the Python Client Library. I am getting a DEVELOPER_TOKEN_NOT_APPROVED error when I run my test application.
After a lot of research on the issue, I figured maybe I didn't set up the production and test accounts properly which I am still struggling with. I really hope you can put me through the process as I am running against time.
Looking forward to your help
Thank you very much.
You need Developer Token from production account, but until approval is pending you need authorize API call only for test AdWords account. You need two different Google accounts. You must get Refresh Token after login to your another Google account for testing purpose.
More info: https://developers.google.com/adwords/api/docs/guides/accounts-overview#test_accounts
We already have a web app that integrate with differente Google services. Right now, you can loguin using a Google account, can import a contact lists from any Google account, and can sync a Google Calendar with our Calendar in the webapp (We implemented all of this using OAuth 2 and invoking the GoogleApi with a REST Client).
We are now trying to publish this app in the GoogleApp Marketplace, but we are failing to comply with the "Use one-click single sign-on" rule (https://developers.google.com/apps-marketplace/practices#5_use_one-click_single_sign-on).
We are believing that the problem is we the way we are solving the fact that we need offline access for all the integrated users in the app. Right now, the only way we found to get the refresh tokens for them, was starting the OAuth2 process with the parameters access_type=offline&approval_prompt=force, but this forces them to enter their credentials.
We aren't using the 'Google+ Domains API', and we are starting to believe that we should. Is the use of this API mandatory for complying with the "Use one-click single sign-on" rule?
Thanks,
Well, we finally figured it out. We had to use the Google Admin SDK in order to implement SSO. We had some troubles with the scopes, but after we polished that, everything seems to be working OK.
ok, I've spent 2 hours googling on what it is & how to use it in a web-application! but no success.
Most of the links talk about scanning codes or entering some key in the GoogleAuthenticar mobile app and it'll return changing verification codes every 30 seconds.
Few things :
The webapplication has it's own login. That means users don't login using Google into the webapp.
If an attacker gets the user's password, he sees the QRcode as the next-step, which he can scan directly with the GoogleAuthenticator app in his mobile (as far as it appears to me). How is it tied to user's mobile only ?
In various sites, it mentions a shared secret between user & server, that means at the time of signup, we provide the user the shared-secret, which he can use in her mobile GoogleAuthenticator app and then use it while reading the QR code ?
In the above case, how to proceed if the secret is lost or forgotten by the user ? Use forget secret to send the secret again to user's email ?
I am confused about how can it be implemented in a fashion when it's a non-google non-android application!
All I get is that, it's just a concept asking for our own implementation with some help from the source-code of the GoogleAuthenticator. Please correct me ?
What I think is the solution is that, we have to write our own mobile-app, just like this guy mentioned here, although I'm still not sure how will the secret between the mobile-app and the server will be unique with each installation of that app such that it identifies a particular user only or is there any way to write our own app and use GoogleAuthenticator mobile app without having Google-login in our webapp ?
Google Authenticator (the mobile application) implements the Time-based One-time Password Algorithm. In the scenario you are asking about, two-factor authentication would work as follows:
The user generates a one-time password to be validated by a server application.
The server would verify the password using the procedure detailed by the TOTP algorithm.
The password generation on the user device can be performed by any application implementing TOTP which has been "configured" for your user account. Configured here means having shared a secret with the server, as you mention yourself in the question.
Now, trying to answer your questions:
The fact your application uses its own set of user credentials or Google's has no direct effect on two-factor authentication. No matter what these credentials are, you need a way to identify your user (the username) in order to be able to proceed to the validation of its TOTP password, because you need to know who the user is. Said another way: using TOTP and using the Google Authenticator application does not imply having to use Google credentials on your site.
I'm not sure I understand correctly. The configuration of the Google Authenticator app for each account is performed only once. If an attacker is sitting right behind your back and takes a photo of your screen while you configure Google Authenticator, then yes, he'd be able to configure its own application with your credentials reading the same barcode you're using. Nevertheless, he'd also need your credentials (proper) in order to perform the login and then provide the one-time TOTP password. Anyway, this is a security problem which stems from how the user improperly handles its own credentials and you could be subject to similar problems no matter the technology you use. To make an imperfect metaphor, it's like asking "if the user leaves the pin card with the codes on the table, an attacker sees it and steals a photo of it, could it use them?". Sure, he could.
Yes, reading the barcode is one of the ways you can configure the application and sharing the secret between the client application and the server. You can use other means, such as entering the key manually into the application, but using the QR code is quicker and much less error prone. You won't even need to generate the QR code, because you could use Google's Web APIs as I explained in the blog post you were reading when you asked me to answer this question. In fact, the Java server side library described there uses the Google Web API's and returns you an URL for the user to check out and read its own QR. If you want to build your own QR logic, go on, but there's no compelling reason you should do that if you're eligible to use Google's APIs (which is something you should check anyway).
If the secret is lost it depends on your own policy, if it's your own application. First of all, you should invalidate the old secret immediately upon user notification. Then, you could use the scratch codes you may have given the user upon creation of the TOTP secret to verify his own identity. If he has lost the scratch codes too, you'd probably want to fall back to some other ways to verify his identity such as using some kind of backup information in his account (backup telephone numbers, security questions, etc.). Once the user identity is verified according to your standards, you would issue a new credential and would begin from the start: that is, reconfiguring the Google Authenticator using a new QR and/or a new secret key.
To summarise: yes, you can use the Google Authenticator application as your client front-end if you want to: there's no need to build another one. The only thing which you should into account is that Google Authenticator uses 30-second windows in its TOTP implementation: the server side logic verifying the TOTP password will have to use the same window size (which is, IIRC, the standard value proposed by the TOTP RFC).