I am using google apps provisioning api from java (Idm - Midpoint). Whenewer i create test user it is supended with suspended reason weblogin reqiered. Then account needs to be authenticated by sms.
Other istallation of this software is working fine and newly created users are allowed to login without sms authentization.
Is there any way how to troubleshoot, why google marks my test accounts as suspicious and requires initial weblogin?
As discussed in Authorizing requests,
The authorization scopes accepted by the Profiles and Provisioning APIs have been replaced by several new scopes. Scopes supported by the Profiles and Provisioning APIs are also supported by the Directory API, but new applications should use the existing Directory API scopes.
Furthermore, it was mentioned in User accounts and multi-domain users
The User feed exposed by the Provisining API to manage user accounts has been replaced by the Users resource in the Directory API.
Lastly, please note that the Directory API contains several new features that were not supported by the Provisioning API.
Table map of currently supported scopes of Profiles and Provisioning APIs to their Directory API equivalents and more information can be found in Migrating to the Directory API.
Related
I have a server-side application that needs to access every user's gmail data in a google workspace organization. I want to publish a public listing on the google workspace marketplace that is installable domain-wide by the super admin user and gives the server-side application the permissions to access the gmail data of the user's in that domain.
From my current understanding, we need a service account with impersonation to access each user's data. On top of that the service account needs to be delegated domain-wide authority, so that user's do not need to give individual OAuth consent or their passwords.
When publishing the app using the marketplace SDK I see that there is a field for service account credentials:
I see that the current Marketplace SDK has a field that accepts service account credentials.
But when my app is published and I install it and go to check the app's data access. I can only see fields for the scopes and the Oauth clients.
My questions:
Are the service accounts created in the marketplace SDK usable to the organization that installs my marketplace app? Will the service account's have the same email and unique id for everyone who installs the public listed app?
If (1) is not true, then how is it possible for admins to create a service account for my marketplace app?
If (1) is true, is it automatically granted access unlike the OAuth clients and scopes?
If (1) is true, Are the service accounts automatically delegated domain-wide on install or do we have to provide the person who installed the marketplace app with the service accounts unique ids so they can manually delegate the scopes domain-wide.
I reviewed some Google public documentations related to Service Account & here’s what I have found that may answer your questions:
Question 1
Are the service accounts created in the marketplace SDK usable to the organization that installs my marketplace app?
Answer
No
Note: The CREDENTIALS tab that you see on the Google Workspace Marketplace SDK page is only an overview of credentials you have created for the GCP Project & NOT necessarily only for that service/API.
Service Accounts are created within a specific GCP Project & that project is where you will enable the Google APIs/Services that your application needs. Google Workspace Marketplace SDK is being described as:
“A toolkit that lets you create and control your app listing on the Google Workspace Marketplace, or for Chat apps, in Google Chat.” (Source)
So, this Google Workspace Marketplace SDK doesn’t necessarily use a Service Account to authenticate & be called in your app. However, when you setup a Service Account for your app, you'll need to create a Google Workspace Marketplace OAuth Client & this OAuth Client is associated to that Service Account. This is needed to support Google Workspace Marketplace domain-wide installation.
Setting up the Google Workspace Marketplace OAuth Client from the GCP console:
Follow-up Question
Will the service account's have the same email and unique id for everyone who installs the public listed app?
Answer
Yes. In theory, it should be.
Question 2
If (1) is not true, then how is it possible for admins to create a service account for my marketplace app?
Answer
You have to review the official Google documentation for OAuth & Service account.
Based on the official documentation, this is the overview:
Create a service account for your project
Delegate domain-wide access to the service account
Your application prepares to make authorized API calls using the service account's credentials. (This is regardless of how many users install & use your app)
That API call will request an access token from the OAuth 2.0 auth server.
Your application will then be able to use the access token to call Google APIs (which in your case uses Gmail API).
I'm working on a Slack integration for our workspace that is within an Enterprise Grid. I have a workspace and I've created a Slack App with all possible OAuth scopes and have installed it in the workspace.
I'd like to automatically invite and remove users to our workspace using the app/bot. I should be able to do this with the Slack app/bot using the admin.users.invite and admin.users.remove API actions.
However, these two actions require the admin.users:write OAuth scope, which can only be used on an App that is installed organization-wide, so I can't use this scope on my workspace app:
The app requesting this scope must be installed by an admin or Owner of an Enterprise Grid organization. Also, the app must be installed on the entire org, not on an individual workspace.
Is there any other way I can have an automated system that invites/removes users to/from our workspace, without it being an organization-wide app? This is something I can do as a user through the Slack UI (and I'm not an organization admin, just a workspace admin), so one would think I should be able to do the same things via an app/bot that is installed and authorized to act on my behalf.
Unfortunately, the APIs currently provided by Slack are available for Org Owner & Org Admin roles.
The best course of action for you will be to collaborate with your org admins. Let them manage the app. It means you will not have access to token, but you can use the app as a user.
Create the app that will operate only on your workspace by using fixed teamId.
Ask the org admin to generate the admin token and update that in your app.
May be, if they find your app useful, it can be used across organization eventually.
We have changed the required scopes of our application in the marketplace SDK but on install the app is still requesting the old scopes.
What are we missing?
See also:
https://issuetracker.google.com/issues/72450194
Based from this link, old scopes (that were requested and approved by user and you delete them from your marketplace SDK configuration page) that were approved by user at certain time will still remain approved for the user until he revokes the data access and re-grant it again. This may be the reason why the old scopes are available. Also from this documentation:
To update OAuth scopes, enable new extensions, and other application settings, go to Google API Console. Click APIs, then go to the Configuration tab under G Suite Marketplace SDK.
We have an existing web app which uses Google's OAuth 2.0 APIs for Admin Directory, Drive, etc for administrative tasks like backup and audit.
Currently we let our customers install backup and audit independently as 'modules' and each have separate client_ids and separate OAuth scopes (i.e. Admin directory for one, Drive for another).
We want to bring our app to the Google Apps Marketplace, and take advantage of Google Sign In (OpenID Connect), use service accounts with domain-wide delegation of authority, but still let our customers only authorize scopes they want to use.
Can we add new scopes to Google Apps Marketplace apps when a user wants to enable a certain feature?
The best practise guidelines (1) indicate that we should request all scopes we might want up front via the Marketplace SDK scopes section but we want to only request the scopes our customers are going to actually use.
(1) https://developers.google.com/apps-marketplace/practices#1_complete_the_listing_review_request_form
You can add new scopes. Your customer will still have to grant access though for the new scope/s from the ADMIN console.
We're trying to figure out how to submit to the marketplace, but are not sure what we need to do to alter our existing signup flow to accomodate the SSO requirement
Our app was not originally built to be a marketplace app so our signup flow is built for individual users. We are already following the OAuth2 flow as outlined on this documentation page. However, its not clear to me how this works for an entire org when installing from the context of a marketplace app.
Does the admin grant access to all the individual scopes we currently request for the entire org at once? Is there need for some sort of service account or something since we currently are requesting offline access? I'd like to understand what changes we need to make to our server's signup flow in or whether it is just a scope / manifest mismatch.
We currently request the following scopes from an individual user when signing up.
['email', 'profile' ,'https://mail.google.com/', 'https://www.googleapis.com/auth/calendar'],
Exact questions are...
What (if anything) do we need to do to alter our current individual-focused signup flow to accommodate a Google Apps Admin signing up their whole domain?
What scopes do we need to in our Google Apps Admin listing and how do they relate to the scopes we currently request from individuals?
There are not so many changes if you are already using three legged OAuth2.
The first change would be in you project in the developer console. There you need to enable the Marketplace SDK and make the necessary configurations. Here you will add the scopes that your app will request and those are the scopes that the admin will see when installing the app.
The admin will see the scopes your app is requesting, and he will decide if it's ok to install the application in the domain. If it is approved, then yes, the admin would grant access to the entire domain.
Offline access is part of the Oauth flow, after you receive the refresh token, you can continue refreshing the access token without having the user to grant access again.
It is not necessary to have a service account. The service account has two purposes:
To manage information related to the application. In this case the service account can have access to it's own drive to store and retrieve information that is related to the app functionality.
Impersonation of users. When using domain delegation of authority, you can use a service account to impersonate any user in a domain and act on it's behalf to make API calls.
To deploy your app, you also have to create a new project in the Chrome Web Store, with a manifest for Marketplace.
To answer your questions:
It's not necessary that you modify your current oauth flow. The admin will install the app in the domain, but when a user access to the app, the process for authentication is the same as individual.
The scopes in your Marketplace SDK configuration should match the scopes your app will use. This is mostly for security reasons, it wouldn't be safe if you install an app with some scopes and then the app uses different scopes.
You can try your app before actually deploying it by adding trusted testers in the chrome web store dashboard or in the Console API configuration. This way you can check if your flows and all the configurations were done correctly.
Hope this helps. Let me know if you have more questions.