I'm using this site for testing:
https://developers.google.com/classroom/reference/rest/v1/courses/list
I have a project setup with a service account:
The account was created with read only domain access.
A project was setup after the fact.
I then added the account after the fact.
I then enabled the Classroom API in that project.
I added the courses scope at the site linked above to domain wide delegation for the service account.
My admin account gets a 200 response with a full list of courses. My service account gets an empty 200 response. If I grant the service account domain admin it returns a full list of courses. I'm happy to provide sanitized screen shots if needed but does anyone know what rights a service account needs short of domain admin to be able to access Google classroom data through the APIs?
Impersonating an account in the domain:
A service account that has been granted domain-wide authority can access the same data than the account it is impersonating.
As explained in this answer, only domain administrators can access all the courses in the domain. The rest of users can only access the courses they are part of (as teachers, students, etc.).
So the only way for a service account to retrieve all courses in the domain is to impersonate a domain admin (or have another account added to each course in the domain).
Service account by itself:
On the other side, a service account that has not been granted domain-wide authority or that is not using this authority to impersonate another account, will only have access to the courses it has been added to.
And since a service account is technically not part of the domain, it cannot be added to a course in the domain (only accounts within the domain can be added to a course – what sense would it make, anyway, to have a service account as a teacher or a student of a course?).
So, a call to courses.list cannot return any course in the domain: it will return any courses that the service account might have created on its own, which are not part of the domain.
Reference:
Using OAuth 2.0 for Server to Server Applications
Related
I'm working on one school app. I'm able to create events using google calender API with NodeJS. I created the clientID and secretID on the school google account. Every time event is created, only the admin has access to start the meeting. But I want teachers(who are creating the event) to be the organizer. How can I achieve this?
The organizer field of an event is a read-only field. You can use the move action to move the event and change the organizer but this can only be done if the authenticated user has write access to the destination calendar.
A solution would be to use a service account and perform domain wide delegation. In this way you will be able to impersonate the user in question and organize the event wanted.
According to the Service accounts documentation:
A service account is a special kind of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls.
As for performing domain-wide delegation, you might want to take a look into this:
In enterprise applications you may want to programmatically access users data without any manual authorization on their part. In G Suite domains, the domain administrator can grant to third party applications domain-wide access to its users' data — this is referred as domain-wide delegation of authority. To delegate authority this way, domain administrators can use service accounts with OAuth 2.0.
Reference
Calendar API - Events:move;
Service Accounts;
Calendar API - Perform G Suite Domain-Wide Delegation of Authority;
Using OAuth 2.0 for Server to Server Applications.
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 have a service account created through the Google developer console specifically for API access to Google Drive to retrieve documents. However recently I have changed my G-suite Google Drive settings to have the security restriction that documents can only be shared outside of my organization to whitelisted domains rather than it being wide-open for sharing purposes.
Prior to this security setting change everything was working fine having my service account access documents it has specifically been granted access to. However after the change when viewing the sharing settings on a file that it previously had access to it now says the account cannot be granted access as the policy set prohibits the sharing of items to this user as its not in a compatible whitelisted domain.
I did try whitelisting gserviceaccount.com within my G-suite admin console but this still brought no luck.
Anyone else have a similar issue? Any good solution?
Thanks!
You may want to complete the following steps given in Delegating domain-wide authority to the service account:
Go to your G Suite domain’s Admin console.
Select Security from the list of controls. If you don't see Security listed, select More controls from the gray bar at the bottom of the page, then select Security from the list of controls. If you can't see the controls, make sure you're signed in as an administrator for the domain.
Select Show more and then Advanced settings from the list of options.
Select Manage API client access in the Authentication section.
In the Client Name field enter the service account's Client ID. You can find your service account's client ID in the Service accounts page.
In the One or More API Scopes field enter the list of scopes that your application should be granted access to. For example, if your application needs domain-wide access to the Google Drive API and the Google Calendar API, enter: https://www.googleapis.com/auth/drive, https://www.googleapis.com/auth/calendar.
Click Authorize.
This will give authority to your app to make application calls as users in your domain. However, please note on this:
Although you can use service accounts in applications that run from a G Suite domain, service accounts are not members of your G Suite account and aren’t subject to domain policies set by G Suite administrators. For example, a policy set in the G Suite admin console to restrict the ability of G Suite end users to share documents outside of the domain would not apply to service accounts.
See Perform G Suite Domain-Wide Delegation of Authority for more information.
I'm trying to create contacts in my google account using the 2lo (2 legged oauth), to achieve this Ive created a service account using my test account AAAAAAA#gmail.com, this step creates a "new email address" for the service, something like: XXXXXXX#YYYYYYYY.iam.gserviceaccount.com.
I'm able to access the google api with this account without the user intervention (2lo), and when I create a new contact using the api, this contact is related to XXXXXXX#YYYYYYYY.iam.gserviceaccount.com and not to the account I used to create the service account AAAAAAA#gmail.com, I can't see the created contact using my test account (AAAAAAA#gmail.com).
Is it possible to create a contact on my AAAAAAA#gmail.com account using a service account? what steps shou;d I follow?
Thanks
No, you cannot create contact. You need service account, which is an account that belongs to your application instead of an individual end user. Your application calls Google APIs on behalf of the service account, so users aren't directly involved.
If you want to access user data for users in your Google Apps domain, then delegate domain-wide access to the service account. Then, your application prepares to make authorized API calls by using the service account's credentials to request an access token from the OAuth 2.0 auth server.
You may follow the steps listed here: . It shows how to create a service account.
I'm looking to do an integration that makes use of a shared calendar for the domain my app is installed on. My initial plan was to create the calendar under the domain admin that is shared with the rest of the users on the domain. My concern though is what happens if the domain admin changes?
It seems like that calendar could potentially be lost. What are the best practices in this circumstance? Should I be making an admin account for myself at the time of install? Or should I be creating calendars under my service account?
When admin is changed for a domain, before changing, another admin should be assigned. It cannot happen domain with no admin. So, the new admin gets all the rights to the calendar.
If you want to maintain a single calendar and share with all the users in the domain better go with Admin account.
If you want to have individual calendars to all the users and want to access their calendars, go with service account. With service account you have to do domain wide delegation means sharing your service account to the calendar. Also, users initially should give access to the service account to access the information.
Check this link and this link for calendar sharing options.