Assume we have an app on G Suite Marketplace, and a G Suite domain administrator wants to delegate domain-wide access to the domain's users' data (as explained here).
For signup purposes, the 3rd service itself needs to know the domain name and the username of the administrator who performed domain-wide delegation of authority. This is needed to be able to use the Directory API (see note here)
I can easily get the domain name (by using Universal Navigation Extension, and adding ${DOMAIN_NAME} to the callback URL, as explained here). However, I didn't find a way to programmatically access the username of the administrator who performed DWD.
Any hints how to do that? Or if that is possible at all?
Thanks in advance!
Method 1:
When the user clicks in the launcher link (or just during installation with the configuration link you can configure) you need to do the OAuth2 flow and obtain the user email. Then you use the email assuming it is from an admin and it usually should be. If not, just return an error and wait for the admin login.
Method 2: ONLY TO GET THE DOMAIN, not the user.
Use the Marketplace License API https://developers.google.com/gsuite/marketplace/v2/reference
You can periodically use the list endpoint and find the user that installs (or removes) your application.
In any case you should store the list of domain super admins to be used when necessary.
Related
We are trying to create a separate Admin role to assign to users to be able to call the Google Classroom API (domain). If we set them to be 'super admin' it works but we do not want to give these users super admin permissions. Anyone knows any guide or the settings to set on this?
Answer:
There is no role apart from Super Admin that will let a user make all these actions. You can check that by assigning custom admin roles to the user. Even if all possible privileges are checked, if the user is not a Super Admin, the user cannot act as a domain administrator in Classroom API.
What non-Super Admins can do:
Non-super admin users can only access courses they are part of (as teachers, or students), not all courses in the domain.
They can remove students and other teachers from courses they own directly via courses.teachers.delete and courses.students.delete, but they cannot directly add new students and teachers to their courses via courses.teachers.create and courses.students.create. Only domain administrators (Super Admins) can do that. Non-admins must first send an invitation via invitations.create(), and obtain the user's consent.
Update: Service Accounts:
You can also make your application use a Service Account in order to impersonate a Super Admin, so that this account can act on behalf of this admin, and do what the admin can do. To do this, you would have to create the Service Account and delegate domain-wide authority to it, by visiting the Admin console and following the steps specified here.
Beware, granting domain-wide delegation is a very powerful tool, since it gives the Service Account the ability to act on behalf of any user in the domain, so it could be easily abused if not managed carefully (without domain-wide delegation, a Service Account is similar to a regular account, and it can only access resources that have been created by it, shared with it, etc., like a regular account).
Anyway, once the domain-wide delegation is created, using the Service Account in your application is very similar to using a regular account. In the application, you have to build the credentials and then specify which user should be impersonated by the account by writing the user's email address. I don't know which language are you using, but you can find code snippets to do this in Java and Python here, or with Node here.
Reference:
Create custom administrator roles
Manage Teachers and Students
I need to have access to Calendar information from a company's G Suite accounts, to synchronize data with the company system through a API.
When I need to provide access to my own data, there is a fairly simple way to do it. Using Oauth2, through a login window the user allows the API to access the requested data.
But in the G Suite documentation, the path indicated when involving the administrator and company data, involves the administrator accessing admin.google.com, go to the security-related session, and manually register my API, listing the scopes that he wants to grant me access.
To make a parallel, in Microsoft Graph there is a way to request consent from the domain administrator, where only a user consent / admin consent screen is displayed using Oauth2.
I wonder if there is a way to get this type of access in G Suite without requiring the end user to take such complicated steps to make my API work properly.
UPDATE:
This question was originally posted in 2019, does anyone aware if something was changes since then?
You should use the Marketplace SDK for this. This allows you to publish an application to the Google Workspace Marketplace where company admins can choose to install it for their domain.
There are a couple things to keep in mind:
There's an expectation that your application will have some sort of user facing presence (e.g. add-on, link to web app, etc).
Google will review your app before publishing. Since you're not using Gmail or Drive scopes (for these, Google requires a 3rd party security review), this process should not be too difficult. But plan for it to take some time, and follow the best practices so it's done right the first time.
You also mentioned synchronizing calendars. If that means mainly reading, no problem, but if you're writing (a lot at once), be mindful of calendar use limits. These are per user and for all activity by that user (not just your app).
I've created a service account in G-Suite and delegated it domain wide authorization so that I can collect information on all the Drives within the suite.
The problem I've come across is that I need a list of all the users within the domain. To do so I can call the Directory API, but the problem is that I actually need to do that as one of the admins. The problem is that I can't know who the admins are without using one of the admins(or users? I confirmed the call to the directory API with a superadmin account). Is there a way to call the Directory API without a user email? Or is there a way to as the service account to get a list of the admins so that I can make API calls on their behalf?
To use Directory API, you must** impersonate one of the admins of the domain, as you say. There really isn't any way around it (as far as I'm aware) - you must ask the admin who's installing your app to provide their email address.
** For some activities, like listing all users, you can impersonate an end user, but that doesn't solve your problem.
I have an application using Google Drive that must (a) not require user login and (b) populate a document that authorised users can view.
Because of this it appears that using a regular account as a service account is my only option, as described here https://developers.google.com/drive/web/service-accounts
Use regular Google accounts as application-owned accounts
You may create a regular Google account like any user would, by going
through the Google account sign-up flow or by creating an account on
your Google Apps domain. Make sure it is then never used by an actual
person but only by your application.
To be able to access the account’s Drive programmatically you need to
manually go through the OAuth 2.0 web-server flow once and then store
or hard-code the user’s credentials, such as the refresh token, to be
able to programmatically access its Drive. For more information about
the web server flow for Drive, see Implementing Server-side
Authorization.
While it discourages user access, it doesn't ban it. However I am confused by the line
you need to manually go through the OAuth 2.0 web-server flow once and
then store or hard-code the user’s credentials
There doesn't seem to be a documented way to do this (yes, I have searched) - could someone step me though it?
You don't use a regular account as a service account, these are different things. Each one is a type of application-owned account.
The regular account is just a normal Google account that your application uses. Since regular accounts require the manual authorization step (going to the browser, logging in to Google and authorizing your app), you need to do this manually the first time and then save the token. There's some examples in this page. After you save the token, your app can authorize itself without your intervention.
The service account is an account that is not associated with an user and that do not require manual authorization. You can create a service account in the Developers Console as described here. With this type of account, you use a private key file to authorize your app.
Unless you need access to the web interface of the account that will manage your files (for example, to buy more storage), I'd recommend using the service account, since it doesn't require the manual step.
I am using Google Admin SDK Directory API to create users and using Service account I am able to perform CRUD operations on them.
I have a requirement whereby I have to check the credentials of users created using SDK.
When you fetch the users the password is not returned, hence comparison cannot be done.
I'll really appreciate if someone lets me know what would be effective way of approaching the checkCredentials function.
Thanks.
Google does not ever return the value of the password. That would be a monumental security risk.
See their documentation in regards to the user resource used in the directory API. It specifically states that the password field is never returned. It can only be used for setting the password.
If your requirement is too check creds on a newly created user, you should look into trying to login as the user with the password you just sent, using the google auth Apis
At the moment, the only solution I've found is to simulate the user login flow with a fake browser (Apache's httpcomponents-client for Java for example) pointing to Google Account ServiceLogin.