My normal, non-admin G Suite users need to work out (programatically) whether they are in a specific G Suite group or not.
Plan A - G Suite Admin SDK
It would appear that one can do that with this call:
https://admin.googleapis.com/admin/directory/v1/groups/developers#example.com/hasMember/max#example.com
This does not work. If I authenticate as an admin, it works. But if I authenticate as max#example.com (note: I added all relevant scopes to token request), I get a 403 "Not Authorized to access this resource/api".
Is it intended that a user cannot query his own group membership via the G Suite Admin SDK?
Plan B - Google People API
I tried this API:
https://people.googleapis.com/v1/people/me?personFields=memberships
This returns a successful 200 response, but the group membership is not in there. The response is something like this, which is basically the standard empty response for that API:
{
"resourceName": "people/107804923746527240895",
"etag": "%EgMBNy4aBEAABQc="
}
Which API call can I make to find out whether I'm in a group or not?
Is it intended that a user cannot query his own group membership via the G Suite Admin SDK?
As the name says - it is an Admin Software development Kit - designed for admins. So unfortunately not accessible by non-admin users.
group membership is not in there
Unfortunately the People API only returns you
"domainMembership": {
"inViewerDomain": true
}
if you are an admin - so again not useful for you.
Conclusion - it is currently not possible for a user to see his group memberships
However, Google Public Issue Tracker allows you to file feature requests. This would allow you to let Google know that an important feature is missing and users request for it to be implemented.
Related
Assume we have an app on G Suite Marketplace, and a G Suite domain administrator wants to delegate domain-wide access to the domain's users' data (as explained here).
For signup purposes, the 3rd service itself needs to know the domain name and the username of the administrator who performed domain-wide delegation of authority. This is needed to be able to use the Directory API (see note here)
I can easily get the domain name (by using Universal Navigation Extension, and adding ${DOMAIN_NAME} to the callback URL, as explained here). However, I didn't find a way to programmatically access the username of the administrator who performed DWD.
Any hints how to do that? Or if that is possible at all?
Thanks in advance!
Method 1:
When the user clicks in the launcher link (or just during installation with the configuration link you can configure) you need to do the OAuth2 flow and obtain the user email. Then you use the email assuming it is from an admin and it usually should be. If not, just return an error and wait for the admin login.
Method 2: ONLY TO GET THE DOMAIN, not the user.
Use the Marketplace License API https://developers.google.com/gsuite/marketplace/v2/reference
You can periodically use the list endpoint and find the user that installs (or removes) your application.
In any case you should store the list of domain super admins to be used when necessary.
I'm in throws of moving our security architecture from ASP.NET Core Identity to Azure AD V2 with MSAL.js. We used a lot of Roles with the ASP.NET Core Identity implementation and the information was managed in the database using the web application. The pattern I'm abandoning is similar to this one.
https://www.dotnetcurry.com/aspnet-core/role-based-security
Azure AD with MSAL is working. The tokens are being created and passed and the local Web API Endpoints decorated with the generic [Authorize] attribute are being honored as you would expect. Web API Endpoints decorated with [Authorize(Roles= "Fee, Foo, Fi, Fum")] are throwing a 401 unauthorized error.
I'm not sure where to go from here. Do I write a CustomAuthorize attribute override for Web API and go back to the database and grab the roles. (probably match the DB defined roles to the user based on email address)
OR
Is there a way to implement roles natively with Azure AD V2?
I'm not sure whats the best course of action from here. Documentation and Code samples seem limited. It would sure be nice to just throw a AD User in a Group and have the Group be respected as a Role in the Web API. On the other hand, It's nice to have Role delegation handled within the confines of the Web Application.
Any advice, experience or interest would be greatly appreciated.
Answer
Follow up to my question. #Marc , You're correct, after looking at the token the Roles are not present. Adding Roles to the token seems pretty straight forward. You need to Patch the graph schema to include them, Configure the roles and assign them to users as needed thru AAD.
Or that's how it looks at first glance. After digging a deeper, it requires a P1 or P2 Enterprise license which only costs an additional 6$ per month per user. This will literally double the cost of hosting email in the cloud for us.
Alternatively I wrote a CustomAuthAttribute for WebAPI and tied User & Roles together on the server backend. Roles can still be managed via the web application and users can still login using Active Directory Credentials.
I recall that the id token returned in implicit flow (the one you use with JS) does not include app roles (or groups). I cannot find any docs confirming that but see others who got around the issue (so the issue must be there) by using Graph to get the roles (or groups).
You can capture the token you receive from AAD and view it using https://jwt.ms to see whether roles are included in it.
I'm developing integration with Google Ads API using their Ruby gem library.
I have an approved oAuth2 account for the Ads scope with an approved developer token that allows any external user to connect with our API.
I have a Google Ads account that manages our own Ads account and two other accounts.
When I authenticate with the API and approve it, I then grab the account with
graph = get_accounts_graph()
Apps::GoogleAds::Account.get_accounts_map(graph)
This surprisingly returns just ONE Ads account, and one that belongs to a client that we manage. Our own two Ads accounts are missing.
So I tried to compare between our client's account and our own.
Under https://ads.google.com/aw/accountaccess I can clearly see we have admin rights to our two ad accounts, just like we do to the client account.
Am I missing some setting somewhere? Has anyone experienced this before?
I ran into this issue at the beginning. The sample in the API client libraries (which I'm going to assume you are using here), calls the customer service
customer_service.list_accessible_customers()
There's actually two different services for retrieving customer account IDs. The customer service only allows access to accounts that are added as direct admins on each account. This is an important distinction as manager accounts don't fall into this category.
What you need to call is the regular GoogleAdsService (not the customer service!) and put your request in the query itself..
query = "SELECT customer_client_link.client_customer FROM customer_client_link"
This will give you a list of account IDs as resource names, not accessible accounts. And you can iterate over them as usual.
Hope that helps.
It always updates my user profile instead of the user that I specify in X-Slack-User:
https://slack.com/api/users.profile.set?token=yadayadayada&X-Slack-User=XYZ23456&Content-type=application/json&charset=utf-8&profile={"status_text": "Test #1","status_emoji": ":gb:","status_expiration": "5"}
The user Ids that I tried to specify are valid ones, I'm an admin and I created an app with the required rights, the legacy token did no good as well, this works, but just for my user, X-Slack-User is not working in my case.
I'm on a free plan so passing "user" as a param doesn't work for me, as states the API: "ID of user to change. This argument may only be specified by team admins on paid teams."
Is there maybe another way to update the status of other users on a free plan Slack?
As you already stated the API method users.profile.set can only be used to change the profile of other users if you are an admin and on a paid team. A property X-Slack-User is not part of the API, so it will not work either.
There is a workaround for teams on a free plan tough:
The API method will always work to change the profile for the owner of a token. You could collect tokens from all you users and then use those to change the status for each user. For that each user will have to install your app though OAuth once. This will create individual tokens for each user, which your app needs to store. This is called "configurations".
I have a service account created through the Google developer console specifically for API access to Google Drive to retrieve documents. However recently I have changed my G-suite Google Drive settings to have the security restriction that documents can only be shared outside of my organization to whitelisted domains rather than it being wide-open for sharing purposes.
Prior to this security setting change everything was working fine having my service account access documents it has specifically been granted access to. However after the change when viewing the sharing settings on a file that it previously had access to it now says the account cannot be granted access as the policy set prohibits the sharing of items to this user as its not in a compatible whitelisted domain.
I did try whitelisting gserviceaccount.com within my G-suite admin console but this still brought no luck.
Anyone else have a similar issue? Any good solution?
Thanks!
You may want to complete the following steps given in Delegating domain-wide authority to the service account:
Go to your G Suite domain’s Admin console.
Select Security from the list of controls. If you don't see Security listed, select More controls from the gray bar at the bottom of the page, then select Security from the list of controls. If you can't see the controls, make sure you're signed in as an administrator for the domain.
Select Show more and then Advanced settings from the list of options.
Select Manage API client access in the Authentication section.
In the Client Name field enter the service account's Client ID. You can find your service account's client ID in the Service accounts page.
In the One or More API Scopes field enter the list of scopes that your application should be granted access to. For example, if your application needs domain-wide access to the Google Drive API and the Google Calendar API, enter: https://www.googleapis.com/auth/drive, https://www.googleapis.com/auth/calendar.
Click Authorize.
This will give authority to your app to make application calls as users in your domain. However, please note on this:
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.
See Perform G Suite Domain-Wide Delegation of Authority for more information.