We have a multi tenant custom app and we provide .zip package and instruct the tenant admin to use the Global Admin login to Microsoft Teams Admin portal (https://admin.teams.microsoft.com/)'s Teams apps --> Manage apps --> Upload new app to upload the App .
We tried it on Microsoft 365 E5 developer tenant with 'Teams service admin' role and 'Application admin' users, But with 'Teams service admin' role app catalog is not shown and we could not upload the app as it throws 'try again and contact MS Support'. We could not event login to the https://admin.teams.microsoft.com portal with 'Application admin' user's credentials.
Is there any least privilege admin role available to install the app or it must require 'Global Admin' ?
Related
How user can add the app in MS Teams, without Admin approval?
So, my question is what policy needs to be added or removed to get rid of the below message:
I am the admin of the tenant and I want my users to install this app if they wish to do so.
If you're a global admin, you can review, and grant consent to apps that request permissions on behalf of all users in your organization.
To grant org-wide consent to an app, follow the steps which mentioned in following document:
https://learn.microsoft.com/en-us/microsoftteams/app-permissions-admin-center#grant-org-wide-admin-consent-to-an-app
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).
Trouble getting Service Account authorized for Marketplace app
In the process of publishing our app, we require two types of consent:
Directory-wide consent by an admin for SSO, on behalf of all users ("https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/userinfo.profile").
Domain-Wide authority of https://www.googleapis.com/auth/calendar.events
The credential type we are using for 1 is OAuth Web ClientId, since there is a browser-based user login. The credential type we are using for 2 is Service Account, since we want to read calendars offline.
The problem is when the app is installed from the marketplace, only the OAuth WebClientId is added to "Authorized API clients" in the installer's Gsuite Admin portal. The service account is not added, and therefore doesn't get access.
What is the solution?
We tried "Enable Domain-Wide authority" on the Service Account, it did create an OAuth Web ClientId, but it does not allow for setting up redirect URLs.
Apparently we already had access via the service account - it is not necessary for the service account client_id to appear in Authorized API Clients"
As long as
1) You enable "domain-wide authority" on the service account
2) The App project is the same project as the service account
It should work
While creating Microsoft app ID under the bot service on Azure, encountering message as "Insufficient privileges to perform this operation. Please ask your administrator to allow users to register applications".
I am using free trial subscription of Azure. How to resolve this issue?
You lack permissions to create application registrations in your company's tenant.
This page has information on what this means.
To summarize so you don't have to read that whole page:
In the Azure Portal, go to your Active Directory tenant.
Click on 'Users and Groups'
Select the 'User Settings' blade.
Under 'App Registrations' see if the setting 'Users can register applications' is set to 'Yes' or 'No'.
It is probably set to 'No'
Your company's Active Directory admin will need to change this setting to 'Yes' in order for you to register your bot app under your company's tenant.
The other option is to have you AD admin register to bot for you and provide to AppId and App Password that is generated.
I have attempted to publish an application to the Google Apps Marketplace that uses a service account to act on behalf of users within a domain. How does the installation flow differ based on whether the installing user is an administrator or a normal user since it requires the service account to be authorized in the Google Admin console?
I am getting push back during the application review asking why the app is requiring an admin to manually authorize the API scopes for the service account in the Google Admin Console. If a Google Apps Administrator installs the application for the domain and consents to all of the application access, does that authorization apply for all users in the domain? I do not want all users in a domain to be prompted with the OAuth 2 consent screen.