I'm looking into using the GMail API to send out emails programtically for one of our systems. I believe I need to create a service account and then set it up with domain-wide-access in order to delegate the email sending ( so the email appears to come from the actual user and not my program ). My question is, if I go this route - is there a way to block out certain users so that the service account cannot "delegate" for them? For example I would like to be able to generate and send emails for our sales team, but I do not want the api to be able to generate any emails for our senior officers.
The flow of things would be....our program gathers info from our database and then loops through this data and uses the gmail api to generate the emails for the sales staff. I'm very new to the google/gmail api and am leery of giving the service account domain-wide-access for delegation.
Is there a "best practice" approach for doing something like this?
Unfortunately it is not possible to restrict domain-wide delegation to only certain users in the admin / cloud console settings
You user enable DOMAIN-WIDE delegation or no delegation at all
You can only control porgrammatically who will be impersonated
One option is to pre-filter your database so that your code is fed only with email addresses of users that you want to impersonate
Another option would be to implement an if statement that retrieves e.g. the orgUnit for each email and does or does not impersonate the user based on his orgUnit (e.g impersonate only the orgUnit "Sales staff")
Related
Inviting a consumer user to Azure AD B2C has been covered by other Stack Overflow questions & answers, and AFAIK requires the use of custom policies that entail a signed JWT being created and used during invite redemption.
What I'm trying to figure out: In our application, we have differently permissioned user groups and different organisations managed by internal RBAC logic. We identify & authorize users based on their oid claim in the access token that's returned to msal-react/msal-browser and used to authenticate against our backend's API.
In Microsoft Graph, a user can be invited and the API will respond with the created user's oid. However, this is the wrong type of user and not appropriate for B2C scenarios.
With the custom policy route not creating the user object in AAD B2C at the time of invite, and therefore without knowing the user's oid at the time of inviting them to the application, what might be the best way to configure their in-app profile and have them identifiable to the application itself upon first login?
My thought at the moment is to have the application store the emails of users that are invited who have not yet redeemed/signed-in. We can configure the emails claim to be returned upon login, which is checked against the invited emails store when an oid claim is returned that isn't present in the database. This can then trigger a function to update the user's internal id with the oid in their first login's claim.
If this is inadvisable or if there's a better way, I'd be very grateful to hear it.
It would work, or just pre create the user up front via MS Graph API. Then you have an email and objectId available.
You could also put an extension attribute on the account indicating whether the user has redeemed their invite. That would allow you to monitor who has redeemed, and also be a way to provide a different experience depending on if the user has redeemed or not redeemed the link.
I am an gsuite/gcp admin and want to forward all emails sent to a group into pubsub without involving any personal accounts.
The process describe here fits my need except for the authentication part. I would instead like to make the forwarding bound to a group and not a user.
https://codelabs.developers.google.com/codelabs/intelligent-gmail-processing/index.html#4
I have an application which needs access to mailboxes for an organization but likely only needs access to the mailboxes for the sales teams and not the mailboxes for the rest of the organization.
For Office 365 we create a service account and get it delegated access to each of the mailboxes it needs to read emails from.
It seems like the Gmail API supports a "userID" parameter.
How can I configure a service account user thru the Admin portal to have access to multiple mailboxes?
Unfortunately this is not possible because a service account acts on behalf of a user who runs the script and does not have the authorization to access other mailboxes.
As a workaround, in the Admin console, the administrator of the domain is able to set up the routing settings for Gmail in a such a way that a copy of all emails addressed to the Sales Team (Organization Unit “Sales Team”) will be delivered to an additional recipient - who will run the API.
When you set-up the routing settings as explained here and add a recipient to whom to deliver a copy of the messages, you can use the option “Advanced”, which allows you to decide to for example to forward attachments or Spam messages as you can see in the image below.
Furthermore, if you don’t want to forward all messages, you can set-up content compliance rules for the inbox of the additional recipient to whom a copy of the messages will be delivered.
I'm creating an application in with angular and nodejs and I need to be able to read another user's list of events. Right now I am attempting to use "https://graph.microsoft.com/v1.0/users/otherusername#companyurl.com/events" this gives me the 403 "Access is denied. Check credentials and try again.". However, if I use "https://graph.microsoft.com/v1.0/users/myusername#companyurl.com/events" it works(as most would expect). My question is, why is it when I use outlook I can use scheduling assistant to see the events for "otherusername#companyurl.com" without being an admin but in my application I cannot see their events due to credentials?
The library I'm using to connect to microsoft graph api is https://github.com/AzureAD/azure-activedirectory-library-for-js
The delegated permissions I have set in azure are
View users' email address
Sign users in
Read user contacts
Have full access to user calendars
Read user calendars
Send mail as a user
Read directory data
Read all users' basic profiles
Sign in and read user profile
Application permissions (I understand these require admin)
Read calendars in all mailboxes
Graph api permission scopes
Any help is appreciated, thankyou.
Fugal - This is by design. You can use FindMeetingTimes API to schedule meetings with other users. This can be accomplished with just Calendar.Read permission. See http://graph.microsoft.io/en-us/docs/api-reference/beta/api/user_findmeetingtimes for more info.
For you to view another user's calendar using /events endpoint, you need a special permission (something like Calendar.Read.Shared) that we are still in the process of adding. Once we add that, you will be able to use /Events to access any calendar that another user has explicitly shared with you. But if you want to just schedule meetings, FindMeetingTimes should be sufficient.
mydomain.com is Google Apps linked to my GAE application (and verified). Currently only one user is allowed at custom domains, so I've registered admin#mydomain.com. Now, I would like to send emails from noreply#mydomain.com. I try to add this user as Developer in Permissions section of my GAE application, it sends the message (which I actually receive at admin#mydomain.com), I accept the invitation as admin#mydomain.com, but it doesn't help.
So, how to send emails from noreply#mydomain.com?
You can enable the trial (lasts for 30 days) and add as many users as you want. You can send emails to them to accept the invitations in GAE and after accepting them you can delete these users to fall back in the free version with only one user.
I have not been able to test the below, as I don't have the new single account Google Apps.
It all depends on if you still want the admin#domain.com user. If not I suggest the following;
For safety link a non-domain email as an owner to your App Engine application
Rename your current Google Apps user from admin to noreply
You should be able to send emails as noreply#domain.com.
If you still want admin#domain.com, maybe you can create an alias for the noreply account?