I am making a very simple marketplace app using the new SDK (Oauth 2.0). One of the steps would be to automatically invite team members for a closed group so I would need access to team members (users in same domain) from the user that is starting the process going through the default "navigator icon in google navigation menu".
This is working fine, however it is only working for administrators (tried with both Directory API and Profiles data API).Is there a way to simply "read" the email from users without needing to have administrator rights? It seems quite an overkill to ask a user to be administrator just for the purpose of being able to invite his team members.
These email addresses are in the user contact list for example, when writing an email they are automatically there so it shoulnt be much of permission problem I guess. can anyone help a bit on how I can accomplish this? Maybe a different API that I have not found?
Very much appreciated,
Best regards,
Joao Garin
You can use "Service Accounts" to access the Directory API on behalf of the Administrator when any user accesses the App.
The Drive API has a really good set of samples here - https://developers.google.com/drive/delegation
This same technique will work with Admin SDK. The end result is the auth is not made on behalf of the user at the keyboard but as an authorized Service Account. This Service Account is authorized by the admin at the time of install.
Related
I'm trying to get some data from a user (searchconsole):
the user first grants permission on a website.
Then, the idea is to use that permission and retrieve the data with a python program that'll run on a different server.
What is the easiest/safest way to achieve that?
Should I use the same token for both servers?
or is there a solution using the service account impersonation? (I'm stuck on that one)
use the permission on the web server to add the service account as a searchconsole user?
I tried to move the token from one server to another manually, and it works, but it seems suboptimal to use the same token for both servers.
I also read the doc and all examples I could find, but didn't find my case even though it seems basic.
Should I use the same token for both servers?
Im not 100% sure what you mean by token, you can and probably should just store the refresh token from the user and then you can access their data when ever you need to. This is really how Oauth2 is supposed to work and maybe you could find a way of storing it in a database that both your fount end and backend can access.
or is there a solution using the service account impersonation? (I'm stuck on that one)
Service accounts should really only be used if you the developer control the account you are trying to connect to. or if you are a google workspace admin and want to control the data of everyone on your domain. impersonation can only be configured via google workspace and can only be configured to control users on the same domain. So standard google gmail users would be out.
In the case of the webmaster tools api im not sure by checking the documentation that this api even supports service accounts
use the permission on the web server to add the service account as a searchconsole user?
I did just check my personal web master tools account and it appears that i have at some point in the past added a service account as a user on my account.
For a service account to have access to an account it must be pre authorized. This is done as you can see by adding a user to your account. I cant remember how long ago I tested this from what i remember it did not work as the user needed to accept the authorization and there was no way to do that with a service account.
I am currently developing a Microsoft Teams tab app using Teams Toolkit.
The users of the app should be able to invite guest users to certain teams and edit some of the users information in AD. This requires higher permission level than the users have.
I have tried to use delegated permission but this limits the permission of the app based on the user's permissions. See https://learn.microsoft.com/en-us/graph/auth/auth-concepts
Is there a way using Teams Toolkit or, as a last resort, some other package to get a Graph API token that will allow the app to perform operations that requires permissions higher that what the user have?
For reference I list below some of the permission the app needs:
"User.ReadBasic.All",
"Sites.ReadWrite.All",
"Domain.ReadWrite.All",
"Directory.ReadWrite.All",
"TeamMember.ReadWrite.All",
"TeamSettings.ReadWrite.All",
Thank you!
Just as Hilton mentioned, you should use "Application" permission for your scenario.
"Application" permission is designed to running from backend, so you can setup a backend web app or Azure Function to do this.
Here are the basic steps:
Go to your AAD app, and add the permission you want
Consent the permission
copy client id and client secret from AAD portal
Follow the steps to get access token
https://learn.microsoft.com/en-us/graph/auth-v2-service#4-get-an-access-token
By the way, recommend to use Azure Function features inside Teams Toolkit, which can help you easily setup an Azure Function in you Teams Tab project, then you can write the code inside the Azure Function to call graph api with application permission
There are two main types of permissions, as you've seen. The first is "Delegated", which basically means the user is "delegating" your app to do something on his/her behalf. This is of course limited to what the user themselves can/can't do, as it's basically just doing it for them. To do something -differently-, or to do without having that specific user associated with it, you need to use Application permissions. In this case, your access is essentially unlimited, BUT it means that a tenant administrator needs to consent upfront (i.e. once-off) to your application having this level of access.
"Application" permissions are therefore what you're needing in your scenario.
I have a custom application for internal use only where currently users are created by a super admin. Some of the users are from within the business and some external e.g. suppliers/customers.
I'm looking for a way to integrate MS Active Directory as a login option but want to be able to restrict which users from the business can actually use this method.
I have search through all the MS docs and have all the documentation on the different oauth approaches but not sure which one would be suitable for my needs.
I am thinking that perhaps i need to give the admin a way to browse the AD and select the users that can login which then creates inactive user accounts in the mysql database with some sort of MS user ID. Then provide a 'Sign in with MS' button that does the usual auth redirection process to MS and back to the site. At that point I can check an ID and if that matches an allowed user account and if so, sync the rest of the data e.g. name, email, phone etc..
Links I've already found:
https://learn.microsoft.com/en-gb/azure/active-directory/develop/authentication-scenarios
https://learn.microsoft.com/en-gb/graph/tutorials/php
https://github.com/microsoftgraph/msgraph-training-phpapp/tree/master/Demos/03-add-msgraph
Your first order of business is enabling a user to sign in to the Laravel-based app. For this, I strongly recommend not trying to re-invent the wheel (at least not completely), and make use of an existing Laravel package. Laravel Socialite is probably the best place to start, since it has a long list of existing community-provided Socialite providers, including three which work with Azure AD already: Microsoft, Microsoft-Graph and Microsoft-Azure. (Note: Though I haven't tested any of these myself, the first two seem to be the most promising, as they use the newer v2 endpoint.)
When it comes to authorization (controlling access), you have two options:
Control at Azure AD
Once you've got the app integrated with Azure AD, you can configure the app in Azure AD to require user assignment, and then control access to the app by assigning (or not) users to the app. Users who are not assigned won't even make it past the sign-in page.
You can use Azure AD's existing experiences for managing user and role assignment for the app, or you could go all-out and build this experience directly into the Laravel-based app itself, making use of the Azure AD Graph API to create the [app role assignments](https://learn.microsoft.com/en-us/previous-versions/azure/ad/graph/api/entity-and-complex-type-reference#approleassignment-entity and user picker experience.
Hint: In either case, remember that you can make the app "superuser" an "owner" of the app in Azure AD (Azure AD > Enterprise apps > (app) > Owners), which will allow them to assign users without needing to give them any additional privileges in Azure AD.
Control at the app
In this approach, you allow all users to sign in to the app with Azure AD, but then you use your app's own authorization logic to decide who makes it any further, and what roles they get in the app.
In reality, you will most likely find the best approach is to use a combination of the two, with some of the authorization enforced by Azure AD and the next level enforced by the app itself.
If you would do it in this way, it will be necessary that the super-admin has always this permissions in the AAD. From my point of view it is less practical.
I would perfer such app-assigments with help of Service Principal. You assign a role (look for app roles) to the user and then your business logic must decide which permissions the user has. If you would use the app roles feature, then you can restrict access to the role with it's help. All the user can login, but only users with a specific role would be able to see a content of the app.
I hope this hints can help to find a right direction, but there is no silver bullet solution... :/
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.
My scenario is as follows:
We built a grade school application that was approved for the Google Marketplace. When the school Google domain administrator installed the application, he had no problems. Going to the application settings he did not expect to see the user the access panel. The application is requiring the domain admin to give access to the school application one user at a time. For a domain with over 2,000 users, giving access to each, one at a time, can become a big problem. I have seen many Google Marketplace Apps where the admin does not have to give access to each domain user, basically because the app is already accessible to all domain users.
What API (such as DIRECTORY API) did we have to include in our application? Or did we miss anything in the Application Manifest to overcome this issue?
As long as you specify the same scopes in the APIs Console as you request in your app, users will not be prompted.