I have 3 email directions (in GSuite) for automatic send email, let's say:
emai1#domain.com
email2#domain.com
email3#domain.com
Actually I use a Service Account with Domain-wide Delegation enable, and with Gmail API Scope: https://www.googleapis.com/auth/gmail.send
I use service account for upload documents to Drive.
My code works as expected, I can send emails with Gmail API with this auth code:
credentials = Google::Auth::ServiceAccountCredentials.make_creds(
json_key_io: f,
scope: g_scope
)
credentials.sub ='email1#domain.com'
credentials.fetch_access_token
My problem is that I want to restrict the users to only three. There is a way to select users for Service Account Delegation?
My problem is that I want to restrict the users to only three. There
is a way to select users for Service Account Delegation?
No, you cannot restrict the service account to being authorized for only certain user accounts. You can restrict the service account to specific permissions (read email, send email, etc.).
From a security posture, you want to be careful with delegated accounts.
Note: 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.
Related
I have to limit which users can access an Azure App. For now, only Global Admins can access using this link:
login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=client_id_goes_here&scope=user.read.all&response_type=code&redirect_uri=https://myredirectbacklink.com/aad/auth&response_mode=query&state=portal&prompt=consent
After redirect back I get Token using
https://login.microsoftonline.com/common/oauth2/v2.0/token and the query contains the same scope as the authorized link.
The flow of the app is the same as documented in Microsoft identity platform and OAuth 2.0 authorization code flow.
My problem is that client wants to allow Billing Admins to access their app. I went through all Graph Permission Scopes, but could not find any related to Billing Admin.
My knowledge of Microsoft's authorization is somewhat limited. I do know that limitations are done by scope. But if it's just link change or is it in Authentication App in Azure (there is one but I don't know how it's related to actual login permissions).
Should I look in a different direction or is it just simply changing the link? Microsoft's documentation didn't help a lot because it's mostly about calendars and other simple stuff.
Careful, requesting a permission that normally requires admin consent and causing the user consent prompt is not the proper way to ensure the user signing in is actually an admin. A non-admin user could simply modify the URL to scope=User.ReadBasic.All and remove prompt=consent. If the user is allowed to consent for User.ReadBasic.All (which is true in many organizations), they'd be able to continue the sign-in. (Or if the organization had granted admin consent for "User.Read.All", the non-admin user would only need to remove prompt=consent.)
If you need to ensure the user is an administrator, you need to explicitly check for directory role assignments.
You can choose from one of three different ways to do this:
You can configure your app to receive the wids claim, which will include the role template IDs of the directory roles for which the user has an active assignment. This is probably the simplest approach.
Using the Azure portal, you can do this under App registrations > (choose your app) > Token configuration > + Add groups claim. You must include "Directory roles" in your selection:
Another option is to a Microsoft Graph API request to check which of a given list of directory roles the user has been assigned:
POST https://graph.microsoft.com/v1.0/me/checkMemberObjects
Content-type: application/json
{
"ids": [
"fdd7a751-b60b-444a-984c-02652fe8fa1c",
"b0f54661-2d74-4c50-afa3-1ec803f12efe"
]
}
A third option is to make a Microsoft Graph API request to list the directory role assignments granted to the user:
GET https://graph.microsoft.com/beta/roleManagement/directory/roleAssignments
?$filter=principalId eq '{id}'
All three of these approaches involve using directory role template IDs to identify the directory role you are checking for. They're all listed here: https://learn.microsoft.com/azure/active-directory/roles/permissions-reference
Some examples you may be interested in:
Application administrator: 9b895d92-2cd3-44c7-9d02-a6ac2d5ea5c3
Cloud application administrator: 158c047a-c907-4556-b7ef-446551a6b5f7
Global administrator: fdd7a751-b60b-444a-984c-02652fe8fa1c
Privileged role administrator: e8611ab8-c189-46e8-94e1-60213ab1f814
Billing administrator: b0f54661-2d74-4c50-afa3-1ec803f12efe
(I included the first four because those are the directory roles which would, by default, be allowed to grant consent for User.Read.All.)
If someone needs solution and uses php:
You can use https://github.com/microsoftgraph/msgraph-sdk-php
$accessToken = 'token from redirect back, called access_token';
$body = [
"ids" => [
"fdd7a751-b60b-444a-984c-02652fe8fa1c",
"b0f54661-2d74-4c50-afa3-1ec803f12efe"
]
];
$graph = new Graph();
$graph->setAccessToken($accessToken);
$user = $graph->createRequest("post", "/me/checkMemberObjects")
->attachBody($body)
->execute();
I need to use G Suite account to insert a calendar include a hangout meet
but I can't even insert the event, I always get the 403 response
403 Forbidden
{
"code" : 403,
"errors" : [ {
"domain" : "calendar",
"message" : "Service accounts cannot invite attendees without Domain-Wide Delegation of Authority.",
"reason" : "forbiddenForServiceAccounts"
} ],
"message" : "Service accounts cannot invite attendees without Domain-Wide Delegation of Authority."
}
I use the GCP p12 file and the service account to do the calendar.
I also click the Enable G Suite domain-wide delegation box and add my clientId and scope of
https://www.googleapis.com/auth/admin.directory.resource.calendar,
https://www.googleapis.com/auth/calendar.events
at G Suite Admin console
What may be the problem!?
By the way, do I need to set the OAuth consent screen!? I already save it, but not been approve by google.
Can anyone help pls!!
In the begining I get credentials by the following code
credentials = new GoogleCredential.Builder().setTransport(httpTransport).setJsonFactory(JSON_FACTORY)
.setServiceAccountId(CalendarEntity.CALENDARID)
.setServiceAccountPrivateKeyFromP12File(new File(P12FILEPATH))
.setServiceAccountScopes(Collections.singleton(CalendarScopes.CALENDAR)).build();
And then I add (my G Suite account)
.setServiceAccountUser("xxx#xxx.com.tw")
it response
401 Unauthorized
How can I slove this!? thx
You are missing impersonation.
The purpose of granting domain-wide authority to a Service Account is for these accounts to be able to access data on behalf of users in the domain.
If you grant it domain-wide authority but are not "impersonating" any account, the Service Account is acting as if you hadn't granted this authority: it is trying to access its own Calendars, Drive files, etc., or in this case, trying to insert an Event: something which the Service Account cannot currently do, as I guess you already know.
When the Service Account impersonates another user in the domain (that is, when it acts on behalf of the user), the Service Account can access the resources this user can access. Nothing more, nothing less. What makes delegation useful is that it can do this with any user in the domain.
To impersonate another user, you have to specify this user's email address. I don't know which library you are using, if any, but here you can see how to impersonate another user with Python, Java, and plain HTTP/REST. Refer to this answer if you need to do it in the Node.js library. If you are using another library, look for the corresponding method in the library documentation.
Reference:
Delegating domain-wide authority to the service account
I have a requirement where Customer care people login with their credentials and have to impersonate the actual users.
You can implement service account flow for same. Using it you can get token of respective client with all allowed scopes to client (This client has all the scope required to access customer care resource).
I have registered a application using the App Registration (Preview) Blade and added the Azure Service Management API as API Permissions I downloaded the MSAL based Sample from
https://github.com/azure-samples/active-directory-dotnet-webapp-openidconnect-v2
Now in startup.auth.cs if i change the Scope i.e keep openid and add https://management.azure.com and then run and try and Login with a Microsoft Account i get the following error
This Doesn't Look like a Work or School Email you cant Sign-in here with Personal Account use your work or School Account Instead.
if i remove the Scope for https://managment.azure.com and just keep Openid profile offline_access i get the Consent Screen and Login
new OpenIdConnectAuthenticationOptions
{
// The Authority represents the v2.0 endpoint - https://login.microsoftonline.com/common/v2.0
// The Scope describes the initial permissions that your app will need. See https://azure.microsoft.com/documentation/articles/active-directory-v2-scopes/
ClientId = clientId,
Authority = String.Format(CultureInfo.InvariantCulture, aadInstance, "common", "/v2.0"),
RedirectUri = redirectUri,
Scope = "openid https://management.azure.com/.default",
PostLogoutRedirectUri = redirectUri,
I am Expecting to have the user Login and Obtain a Token for management API , i am Looking for Reasons for getting the above Error is this Expected ? The Account that i am using exists in my directory as a Member . this works if i use a Managed user(user#tenant.onmicrosoft.com) to Login
Since personal MS accounts cannot be used to manage Azure subscriptions unless they are added to an Azure AD, you should use the organizations endpoint instead of common.
In v1 "common" meant any AAD tenant.
In v2 "common" means any AAD tenant + any personal MS account.
If you wanted only personal accounts, you can use "consumers".
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc#fetch-the-openid-connect-metadata-document
You can use "organizations" to allow any AAD tenant but disallow MS accounts.
Of course a user can just edit the URL and login with a personal MS account anyway, so you'll want to check the tenant id of the logged in user.
The tenant id for MS accounts is always 9188040d-6c67-4c5b-b112-36a304b66dad, per the docs: https://learn.microsoft.com/en-us/azure/active-directory/develop/id-tokens#payload-claims.
So check the idp claim.
I am trying to access emails of an email address in custom domain(my.name#example.com) in google apps. I created service account but I get following error message when trying to read e-mails:
Error:"unauthorized_client", Description:"Unauthorized client or scope
in request.", Uri:""
I found that I have to delegate domain-wide authority to the service account. According to my understanding, after delegating, the service account will have access to all e-mail addresses in the domain(eg; john#example.com, sam#example.com ...). Is my understanding correct. If yes, is there a way that service account has access (can be impersonated) to only one e-mail address in the domain?
Have you authorized the Client Name and the API scopes in the GSuite admin console? It is required for the service account to work and the error you received seems to be related to the API access permissions.
More info at:
https://support.google.com/a/answer/162106?hl=en