I have used service account to manipulate spreadsheet files of all users under same domain.
Now I want to use service account to fetch any user's data.
Can i use service account to read other user's drive data if user is not from my own g-suite domain?
That is absolutely not possible due to privacy and security concerns.
If you want to obtain data from a user which is not part of your domain, that user will have to authenticate to your application by manually completing the OAuth flow.
You may read more at:
Using OAuth 2.0 to Access Google APIs
Using OAuth 2.0 for Web Server Applications
Using OAuth 2.0 for Server to Server Applications
Related
I am currently developing a client-side app where users login using e-mail/password against MongoDB Atlas. The backend runs completely serverless.
All logged in users should be able to upload and retrieve images from GCP - Storage bucket without a visible login, which means the application should authenticate for every user on the background.
I was thinking about using Google Service Accounts in combination with auth0, but I don't know where to start...
If someone could help me tell where to start, that would be great :)
The question is difficult to answer. However, here some insights.
The prefered way is to have a serverless backend, AppEngine standard, Cloud Run or Cloud Function for doing this. The user performs its authentication and then exchange security token between the frontend and the backend. When the user want to reach a GCP resource, it asks the backend, which request the request thanks to its own service account.
By the way, it's easy to trace the user request and to serve him only the resources related to it. And you have only 1 service account, for the backend
If you grant access to a bucket to a user, it could download all the files (But maybe there is one bucket per user?). If you chose to limit object access with ACL, the management is complex.
You don't need to have a service account per user (and in any case, you have a quota to 100 service accounts per project), you can use Cloud Identity Platform (CIP) instead of your MongoDB database for authentication (CIP don't perform authorization, you should use MongoDB for authorization and other stuffs related to authenticated user). CIP is Firebase Auth rebranded
Background:
I have a basic user database with username(email) and password. The users are able to sign in to a website of mine with these credentials. From the website they get a link to different services they have access to, but with different username/passwords. So they click the link "Open My Service X" and they have to login with their service unique login credentials. I do have the users service login-username. So I can map local-user <=> service-user.
I want SSO between service X which has support for SAML and my website.
Question/Problem:
I want the users to login with their user/password in my database, then single sign on towards service X where service X has support for SAML. I don't want a user to be able to sign up for a new user account to my website using the SAML support in service X. The user must already have an account in my database.
So my question might be rather vague, but I'm having a hard time to grasp how this can be achieved?
I was thinking of letting my webapp become a SAML identity provider, so that the SSO request are transferred back to my webapp and verified for their service-user. Would that be correct approach?
You're on the right track with your SAML IdP. There are basically three parts involved. Your email database (the identities), your existing application front end and the remote services which support SAML. Usually it's SAML2 these days.
To get single sign-on (SSO) across your portfolio of apps (your own app and the remote services) you could install an IdP like the Shibboleth IdP and convert your app to use it instead of using email/password to login. That would take a fair amount of work as you'd have to convert your app into a SAML SP, just like the remote services.
An easier way might be to only use the IdP for SAML to the remote services and get the IdP to recognise that your users are already logged in with their email/password. Cookie? So the IdP should never display a login page as it would recognise your app's cookie and match that with a user in the database. It then releases SAML attributes to the remote service based on that user's information. That also covers your use case of not allowing account creation via SAML from a remote service.
That would mean you might end up with the following URLs:
https://yourapp.com/
https://yourapp.com/idp/
Your users login with the first URL as normal and the remote services use the second URL. That way your app cookie will be visible to the /idp endpoint but you'd need to write code to match that with a user in the database.
Here's the scenario
3rd Party App, with a back end. Customer uses the app.
Back end needs to access user's exchange information, assumedly via EWS
Back end is running in our datacenter/cloud, not customers.
Cannot require local administrator involvement
Want to avoid storing username/password in our back end.
Want to support both Office365 and on-premise.
I believe this is currently impossible, but wanted to verify:
Impersonation would be a great way, but requires Administrator
Token based authentication is not used for this. It is for a mail app to use for SSO to the backend, not for the backend to access Exchange.
OAUTH would be ideal, but is a) for Office365 only currently b) requires a portion of the back end to be hosted by Azure c) The Azure install has to be linked to the Office365 install and is for the local administrator only.
Is my analysis correct? Any options I've missed?
You're mostly correct. OAuth is currently for Office 365 only, so that would rule out on-premise. However, with OAuth you do not have to host your back-end in Azure. You would need an Azure tenant to register your application, but the app itself is not required to be hosted in Azure. If you use EWS, then even with OAuth you will need some admin involvement, because EWS requires a permission scope that requires the app to be registered in the target tenant, users can't consent using a registration from another tenant.
If you use the REST APIs, which are in preview, you wouldn't need an admin's involvement, users could consent for themselves. That would get you almost where you want to be (assuming the REST APIs provide the data that you're after), but wouldn't support on-premise.
So to add to this mostly correct answer from Jason:
using pure rest, you need only create a "multitenant" application and users can self-consent.
You can also use an OAuth token to authenticate to EWS - but only if the delegate Full Access To Mailbox is selected. This also doesn't require admin consent but is a big scope (but necessary because EWS doesn't understand scopes)
We have several apps Deployed on Google Apps Marketplace using OAuth 1.0 protocol. According expiration OAuth 1.0 in Google Platform we are trying to migrate all the apps to new OAuth version but we are facing some difficulties regarding background request to Google Admin SDK Directory API.
In our apps we need to request for Domain user accounts, groups and other stuff related Email Domain structure. Until OAuth 1.0 we have been doing this with 2-LO (Two-Legge OAuth) so basically once Admin gave us access we can impersonate request for domain using this mechanism.
After reading all Google Documentation about Google API, Oauth Mechanisms and stuff, and after trying some code test hypothesis too, we haven't figured out yet how can we managed the same concept with OAuth 2 because of the following:
Using Web Server Oauth 2 Strategy simply will not work because in that scenario we would be getting a Domain user Access to Admin SDK. If we keep their access/refresh token pair to later querying Admin SDK and the user is deleted because Domain change it Admin we will be disconnected from flow.
I supposed in that case the best choice was Service Account strategy. The problem with this scenario is the user has to manually configure access to the App in their Admin Console according to the Google's document domain-wide delegation authority (https://developers.google.com/+/domains/authentication/delegation#create_the_service_account_and_its_credentials). This is really awkward for us since we were managing all application installation interactively and we don't want to remove User Experience facilities.
Finally, my questions are:
Is there any way to do domain-delegation authority with OAuth 2 with no manual user configuration, full interactively?
Is there any way to do this without needing user email, which in fact is one of the parameters in Service Account Oauth2 Strategy?
Must we keep 2-LO Authentication for this scenario and do OAuth 2 only for installation Google Marketplace part?
Any comments or guide will be wellcome.
Best,
Certainly - in the latest update to the Google Apps Marketplace, the act of installing an App means the admin doesn't need to do an additional manual step.
You need a way to impersonate a user in a Service Account. Depending on how you implement your application, you might need to utilize the Directory API.
OAuth1 is going away eventually so I recommend you use OAuth2 throughout to simplify your code complexity.
I want to integrate google calendar and analytics from our website's google account in our website's content management system.
So our cms has access to the calendar and analytics without requesting the users to log in.
I'm confused by the documentation that always talk about redirecting, logging in and granting permission with your personal google account.
Could someone point me into the right direction, thanks.
OAuth is a mechanism which allows other applications access to another application's protected resources. In your case, your website wants to access protected resources of a Google account. OAuth does this in multiple steps, but the steps can be summarized as follows:
Your application sends a request to access certain specific protected resources to the OAuth server (which in your case would be Google). At this point you transfer control to the OAuth server; in other words, you are redirecting to the OAuth server.
The OAuth server then shows a page in which it shows to the user a list of the resources that are being requested. The user then has the option to allow the application (which initiated the redirection to the OAuth server) access to the listed resources, or not.
If the user chose not to grant the application access to the listed resources, the workflow ends.
If the user does allow access to listed resources, the OAuth server redirects back to the application, sending an OAuth token along with the redirect.
Once control has been transferred back to the application, it extracts the token from the request. Remember, this token was issued by the OAuth server.
The application can now access the requested protected resources on the OAuth server by sending the token with each request. The OAuth server will recognize the token it just issued and return the protected resource being requested.
A nice page where this workflow is described is: http://hueniverse.com/2007/10/beginners-guide-to-oauth-part-ii-protocol-workflow/
Of course, you should also look into Google's OAuth documentation. They even have a nice OAuth playground where you can play with the OAuth functionality Google offers.