Is anyone aware of any Google API with the user scope (NOT the Admin API in the Directory SDK) that allows you to retrieve the custom employee attributes?
The G+ API seems to skip these
https://developers.google.com/+/web/api/rest/latest/people#resource
Our issue is that we don't want to grant access to the developer console, but rather do this PER-USER. I.E. a user logs into our app and we display to her the custom attributes for her G Suite account, but we do this as her (not as an approved API scope via the dev console).
Leaving this answer for anyone like me who finds this question.
The Directory API allows a user to query the custom attributes for their account even without any admin permissions at all.
https://developers.google.com/admin-sdk/directory/v1/reference/users/get
You need to ensure that projection is set to full and viewType is set to domain_public.
You may need to check the permissions for reading the custom attributes to ensure that a user is allowed to see theirs. We do this in the Google Cloud Directory Sync.
Related
I want to give GSAs direct access to modify Google users. I can't find current docs on this so assuming it's not possible right now?
It looks like this is only possible for working with groups:
https://workspaceupdates.googleblog.com/2020/08/new-api-cloud-identity-groups-google.html
I need to give a GSA access to read group membership and also modify user attributes.
Right now I:
create an admin a G Suite user
create a GSA with domain wide auth with these scopes
https://www.googleapis.com/auth/admin.directory.group
https://www.googleapis.com/auth/admin.directory.user
Impersonate the G Suite user with the GSA and modify user attributes like this:
service = create_directory_service("G SUITE USER")
service.users().update(userKey=uKey, body=myAttributes).execute()
Do I still need domain wide delegation to modify user attributes? Or is it supported now as well?
You can follow this guide to create a Service Account, turning on the Admin SDK API (which allows the service account to provision/manage the users), and authorizing it.
The Service Account created can be used then to provision/manage the G-Suite users, here is a guide on how to manage user accounts using the Directory API, which is part of the Admin SDK.
In short, yes it is possible to manage users too, by using Service Accounts, not just groups.
I'm trying to create an App which has a log in page where user should be authenticated using azure AD. Basically the App has a log in form where user puts his id and password from ad and django should check with ad and allow him in or not. Later on ofc would like to add permission depending on AD group.
So far I searched a lot on the internet and found nothing. Could you guys help with some example or link to documentation what I could use.
First of all, I'd like to suggest that you don't do that.
What you are asking for is ROPC flow: https://joonasw.net/view/ropc-grant-flow-in-azure-ad.
Usage of this flow is not recommended unless this is for migrating a legacy application (which is the original purpose of ROPC).
It also won't work if the user has MFA, an expired password etc.
There is usually no reason why you'd want to handle user passwords when using a federated identity provider.
We're using Google Analytics API in our application and perform actions (read data) on behalf of our users (we get their tokens via OAuth2). We use a client id and client secret to authorize our Google API project (application).
The problem is that we're unable to reach this project in Google's developer console, because the user in our Google App account who created this project was deleted. Regardless, the Google API still works (we have the key and the client secret) but we're unable to reach it in the admin section in the browser, but we can't access it because the owner was deleted.
What are the options to recover access to this API project? Is it possible to transfer ownership of this project using Google API? It's running in production so we can't afford to generate a new API project.
Is it perhaps possible to generate a new API project by keeping all our users consents (they authorize their accounts using an authorization popup in our web app)?
EDIT: it's also possible the user still exists, but we don't know who's the owner. Is it possible to retrieve this info using the app's api key/secret?
How to find out who owns your credentials.
Authenticate your application the pop up window will appear. Click on the name of the application the little arrow and a drop down will apear with the email address of the developer who owns the project.
If you have lost access to this account i am not aware of any way of getting access back. However for the sake of curiosity i am going to contact someone at Google and find out if they have a procedure for account recovery or not. I will update this when i hear back.
If the account that has a credential was a gsuite user then we can transfer the project to the admin of the domain.
Have the admin of the GSuite contact me with information on the project, client id, email of the user who was deleted. We can then add the admin of the gSuite as the owner of the project.
From the question, this was likely a gsuite user because even after the account is deleted, the project was not deleted.
I'm building a lightweight web interface to SSRS where web app users are mapped to web app roles, which in turn are mapped to SSRS users.
The reason for this convoluted scheme is not up for debate: In short, AD groups can't be used, the site uses Forms auth and there are a fixed number of roles.
Web Role | SSRS User
Admin | AdminUser
Supervisor | SuperUser
User | BasicUser
Guest | GuestUser
The goal is to enumerate all reports a user has permission to view, and allow the user to view the report with the ReportViewer control.
More importantly, it's to simplify the UX for users, both admins and the rest: preventing admins from having to use the Report Manager website (ie, selecting checkboxes rather than hand-typing which web-role-users have access to which reports), and providing a simple UI from which users can see and execute all their reports.
Everything works OK when the user is the AdminUser.
However, I'm having difficulty calling the web service when the user isn't included in a Policy on the Home/Root folder with at least the Browser SSRS role. (The permissions granted to user 'computer\username' are insufficient for performing this operation.)
This is problematic for a couple reasons:
If every user must be a Browser to connect to the web service and enumerate reports they have access to view/execute, then all users will have access to all new reports/folders by default. (Children automatically inherit new permissions)
If a report exists in a nested folder that does not inherit permissions and the user is not a browser of, but the user is a Browser on the nested report, ListChildren() will not return that report.
It seems this leaves me with 2 less than ideal options:
Don't call the web service with the different users. Instead, enumerate reports with ListChildren() using only the admin user. Then, for each report, call GetPolicies(), and from that collection of policies, determine what reports the user is able to view.
Make the call with different users. Live with the pitfalls of newly-published reports being accessible to everyone by default, until permissions are changed. Also live with the pitfalls of nested reports not showing unless the user has access to that path. If an admin wants a nested report within a folder with explicit permissions to be available to a user who can't see that folder, the policies on all ancestor folders and their children must be modified.
#1 is obviously very unwieldy and inefficient. But #2 has significant drawbacks and becomes just as onerous & inefficient when setting permissions in certain situations.
Is there a better way? Have I missed something obvious?
[edit]
A 3rd option is to query the ReportServer database directly using a query like this. This has the benefit of returning everything the user has access to, regardless of whether or not it exists in a subfolder the user cannot access (aka, cannot use the web service's ListChildren method to retrieve). However, if using AD groups, I would have to know which groups the user is a member of, whereas the web service would do this for me. This option feels like a bit of a hack to me, but it could work.
As it turns out, we ran an end-route around this issue by dropping the requirement to restrict report access by web role, and made the path we query in the web service a web.config setting that can change, thus allowing report authors to 'hide' reports in a parent folder if the need arises in the future.
The best solution would have been to query the ReportServer database directly.
However, the client changed their mind & didn't want to restrict reports based on web user role in the end, so problem solved!
I am pulling list of docs in coldfusion via google docs API. I want users to click on the link and get signed in automatically in google docs, with my username and password. Google should not ask user name and password from them.
I tried out this example http://cfgoogle.riaforge.org/
Till now I am able to pull up list of documents I have on my google docs account.
But I want anyone to click those link and get automatically signed in as me. And able to access my documents. Is it possible?
I would guess that accessing the documents as you is not possible via the end-user's browser. Google will set a cookie on your computer identifying your session. This allows you access to documents, mail, etc. whatever is linked in your account. For them to be able to access the documents using your account, they would have to be logged in as you. You can't do that directly from your application, because you can only write cookies for your domain (oversimplification, but basically....)
There may, however, be a workaround.
One option would be to use the API to automatically share the document with the user. That is, they provide their Google ID (not password) and you share with their account. This is probably what I would try.
Alternately, you could proxy requests for documents, although this opens up a whole 'nother can of worms.