Does Google use it's own API when using the Google Admin Console to change a chrome device to a different Organizational Unit (OU)?
A school district we support claims that they are having network issues when our service account uses the Directory API to change a chrome device's OU on their behalf. When they moved the devices manually from Google Admin Console, the users claim that their network issues have been resolved.
I have asked the school district to use the user that the service account impersonates in order to make the manual change from Google Admin Console in efforts to replicate the issue, would the user who makes the change be a factor for their network issues?
Is there a difference between using the Directory API and Google Admin Console to change a chrome device's OU?
Related
Assume that there is an application, SPA, that uses Google OAuth2.0 to access the Google Drive API.
Reading the docs, the application flow seems familiar enough on the client-side specially with Google's JavaScript library for authentication. However, I have stumbled upon a roadblock during application registration phase.
When creating the credentials for our client application, I am redirected to fill out the form at the OAuth Consent Screen first. There, among other things it demands us to declare whether the application is in Testing or In Production phase, so it can decide whether the app will be available to everyone or to Test Users only.
Assume I create a project for our application and set it on testing at first and then change it to production once I am ready to publish (with a new set of credentials as well).
My question is this. What if development continues on the application for new features while one instance of the app is in production? During development and testing I would need to restrict the application to my Test Users alone. Since the OAuth consent screen is project specific, not credential specific, will I require multiple projects on the console for every environment in which the application is running?
As in,
Project MyAppTesting will permanently remain in testing mode and will denote our development/testing branch.
Project MyAppProduction is always in production and denotes my production branch.
Similarly for the mobile client:
A MyMobileAppDev project having credentials configured with the debug keystore hash
A MyMobileAppProd project having credentials configured with the production keystore hash.
(both sets of credentials share the same package name).
Is this the idiomatic way? I failed to find any documentation on the matter. Please advise.
What #JohnHanley stated is the best way and the best practice when deploying application/s in GCP.
You can create multiple projects and create different Oauth for each of the projects. Check out this link on service accounts.
In addition to that, there are also some pros and cons when it comes to billing.
Pros:
Users consider having multiple billing accounts with respective projects assigned for each account to be able to see their billing details separately. In this way you can monitor the billing for each of the respective projects for each account.
Cons:
Attaching all the projects to one billing account, however, the billing reports will show all of the sum of the cost for all the projects, but you can still use the filter menu to be able to see the charges for each project.
I'm currently building a web application that works with the Gmail API. I'm waiting for approval from Google's security team to have a proper OAuth connection, but I noticed that users can pre-approve your application by searching within the API Controls settings by your App ID.
This setting is located in the Google Account via: Admin Panel > Security > API Controls > App Access Control.
I noticed that if a user does this before they try to connect your app it doesn't go against your 100 account limit within Google Developer Console while in beta.
My question is, could you have this as permanent solution to get around the Google OAuth application if Google never approves you? Of course, through this method the user is still giving permission, just curious if this has been done by anyone before.
Yes, this is allowed when all your users are Google Workspace users, and is listed under exceptions to verification requirements here: https://support.google.com/cloud/answer/9110914?hl=en. If your application is meant for a broad set of users, completing app verification is necessary.
Yes, this is allowed when all your users are Google Workspace users, and is listed under exceptions to verification requirements here: https://support.google.com/cloud/answer/9110914?hl=en. If your application is meant for a broad set of users, completing app verification is necessary.
Help
For a reporting application deployed on AWS it is required to enable SSO for the users to access it -
The users are to access the application from their office PCs only within the company network.
The application endpoints are protected by an API gateway to only allow access from internal company network.
Once the user clicks on the URL for the reporting application, the app should authenticate the logged in user with the enterprise AD to ensure that the logged in user is a valid one and that they belong to the correct AD groups that are allowed access to the application.
If the authentication and authorization check is passed then the application should allow access to the user or else prompt up a login page to enter the credentials manually.
Can you advise what would be the best approach to set this up ? We have ADFS deployed on our company infrastructure (not sure of the version) so was wondering if we could use that or instead rely on Windows Kerberos authentication to get tokens to allow the user access.
What would be a better approach or more importantly what would be faster to setup. Completely new to SSO and ADFS in general so appreciate your responses.
Thanks!
Raunak
I would recommend you to use ADFS as it is much easier to integrate web apps with ADFS compare to Kerberos.
Kerberos might be tricky. I see you mentioned the reporting app will only be used from company's internal network, but you may still get into the troubles with Kerberos because it requires certain browser setup on the end user machines. On Windows you will have to ensure some IE settings:
IE -> Internet Options -> Security -> Local intranet -> Custom Level -> Make sure you have "Automatic logon only in Intranet zone" is selected.
IE -> Internet Options > Advanced -> make sure "Enable Integrated Windows Authentication" is on
It is very likely that you will also need to add your reporting application URL to the list of intranet sites and trusted sites on each user's PC (in case you use a custom domain name for your app, i.e. not an local server name in your domain)
Other browsers than IE may need a different setup, you can read more details here
I believe it is also a bit more complicated to work with the AD groups as you can only get a user name from a Kerberos token. Then you will have to make an additional call directly to AD to find user's groups. With ADFS you can get groups right from the token (as claims).
Here is a good manual on how to integrate your web app with ADFS: https://auth0.com/docs/connections/enterprise/adfs
We have an existing Android and iOS application that consumes REST API from our servers. The API provides a token to the authenticated users after they log in using their credentials (username, password combo.) from the mobile applications.
Now, we're planning to create a Google Glass application for the same. In this case, we'd like to use the existing REST API along with Glass also. The Glass app will be built natively using the GDK.
My concern is, how would the users be able to input credentials? Because, users may have signed up for the service using non-google accounts?
Many thanks in advance.
At the moment, there is no supported way for apps made with GDK Early Access to authenticate the user or provide a way to connect the Glass account to your auth system. The Glass team has indicated such methods are coming, however - the Strava Cycling app, for example, does this, and it is expected that a similar feature will become widely available as the GDK matures.
Strava Cycling appears to get its credentials at the time you setup the app through MyGlass. When you turn it on it redirects you to a website to log into Strava's service before completing the install.
I just gave a talk on this exact topic at Wearables DevCon. The solution I proposed is purely done through GDK. All the user has to do is sign into their Google Account on a phone/tablet/computer and enter a code that is shown on Glass.
Check out the slides here:
https://docs.google.com/presentation/d/1NepYwlKdEvLV0QH9ix2I8l-JY1kHjBR9AXKBNpgTI6g/edit
And the code here:
https://github.com/victorkp/GlassWebNotes
The latest Glass release (XE16) publishes the remote authentication API for apps distributed through MyGlass:
https://developers.google.com/glass/develop/gdk/authentication
My team is trying to develop a product for the google apps marketplace and I am having issues with the workflow in the new ADMIN SDK.
With the now deprecated Provisioning API we simply ask for a username and password from the account we are trying to manage.
With the ADMIN SDK it seems as though they would need to go enable the API, create a key and do a lot of manual work for this to happen. This really is a tough option for us as the technical level of our clients is not likely to be able to make this transition.
Is there something like the work flow for the provisioning API where they can enable management from a third party or a recommended workflow for a developer to build an application that can access any number of google apps accounts?
A use case for this is say I want to develop a different option for a console, I want to build a console web app and simply ask for credentials or easy setup routine and allow our users to manage their google apps account in a different way.
Thanks in advance,
Steve
The Admin SDK Directory and Reports APIs work correctly with 2-legged OAuth 1.0a which is what the Google Apps Marketplace currently supports and automates. You do need to turn the Admin SDK on under "Register for additional APIs" from your Vendor Profile page on the marketplace. Also, the Administrative APIs for the domain must be turned on. You'll get a generic error that the domain cannot use the APIs if it's off in which case you can direct the client to the exact CPanel page where they can turn it on.