Suppose I have a simple node backend application which when ran needs to connect to a specific GSuite instance, query some things (users, groups, etc.) and then close and not run again until needed, which can mean either a very long time or a few seconds. From what I gathered from Google's documentation there may be multiple ways of doing this, including having an OAuth client and follow the whole flow in setting it up, managing token lifecycle, etc.
However I do NOT want to go with this option for now for various reasons and I am wondering if there is any way of getting access by means of an API Key / secret, like many other 3rd party services allow nowadays. Simply put I would like to generate a key pair somewhere on GSuite, no idea where, and use those keys for auth instead of OAuth, something Google suggests is possible, both on the GSuite Admin app (with a broken link that leads nowhere - not surprising) and on GCloud API and Credentials subpage where you setup credentials (however there it says that API Keys can only be used for very limited resources, none of them having anything to do with GSuite).
I think your best option is to see if what you want to do can be done by a service account. You can create a service account, grant administrator privileges to it in GSuite, enable some APIs, and then that account can do a lot of things without using OAuth directly. The credentials for the service account can then be provided to your application as a json key file, which it can use to authenticate to GSuite. You can also grant service accounts permissions to specific objects like files in Drive, but it doesn't sound like that would be sufficient to your needs.
A guide that may be helpful in the details of how to do this is https://m.fin.com/2017/10/04/navigating-the-google-suite-directory-api/
Related
There are primarily two ways to authenticate using Google's reCAPTCHA Enterprise in a non-Google cloud environment (we use AWS). Google recommends using Service Accounts along with their Java client. However, this approach strikes me as less preferable than the second way Google suggests we can can authenticate, namely, using Api Keys. Authenticating via an Api Key is easy, and it’s similar to how we commonly integrate with other 3rd party services, except rather than a username and password that we must secure, we have an Api Key that we must secure. Authenticating using Service Accounts, however, requires that we store a Json file on each environment in which we run reCAPTCHA, create an environment variable (GOOGLE_APPLICATION_CREDENTIALS) to point to that file, and then use Google's provided Java client (which leverages the environment variable/Json file) to request reCAPTCHA resources.
If we opt to leverage Api Key authentication, we can use Google’s REST Api along with our preferred Http Client (Akka-Http). We merely include the Api Key in a header that is encrypted as part of TLS in transit. However, if we opt for the Service Accounts method, we must use Google’s Java client, which not only adds a new dependency to our service, but also requires its own execution context because it uses blocking i/o.
My view is that unless there is something that I’m overlooking--something that the Service Accounts approach provides that an encrypted Api Key does not--then we should just encrypt an Api Key per environment.
Our Site Key is locked down by our domain, and our Api Key would be encrypted in our source code. Obviously, if someone were to gain access to our unencrypted Api Key, they could perform assessments using our account, but not only would it be exceedingly difficult for an attacker to retrieve our Api Key, the scenario simply doesn't strike me as likely. Performing free reCAPTCHA assessments does not strike me as among the things that a sophisticated attacker would be inclined to do. Am I missing something? I suppose my question is why would we go through the trouble of creating a service account, using the (inferior) Java client, storing a Json file on each pod, create an environment variable, etc. What does that provide us that the Api Key option does not? Does it open up some functionality that I'm overlooking?
I've successfully used Api Keys and it seems to work fine. I have not yet attempted to use Service Accounts as it requires a number of things that I'm disinclined to do. But my worry is that I'm neglecting some security vulnerability of the Api Keys.
After poring a bit more over the documentation, it would seem that there are only two reasons why you'd want to explicitly choose API key-based authentication over an Oauth flow with dedicated service accounts:
Your server's execution environment does not support Oauth flows
You're migrating from reCAPTCHA (non-enterprise) to reCAPTCHA Enterprise and want to ease migration
Beyond that, it seems the choice really comes down to considerations like your organization's security posture and approved authentication patterns. The choice does also materially affect things like how the credentials themselves are provisioned & managed, so if your org happens to already have a robust set of policies in place for the creation and maintenance of service accounts, it'd probably behoove you to go that route.
Google does mention sparingly in the docs that their preferred method for authentication for reCAPTCHA Enterprise is via service accounts, but they also don't give a concrete rationale anywhere I saw.
I have a web application which runs until now with cloud run, but without access restriction. Now it should be available only for certain users.
I read https://cloud.google.com/run/docs/authenticating/end-users and also tried both
mentioned ways: Google-Sign-In and the "Identity Platform" tutorial.
If I understand correctly, you have to program the actual user handling yourself in both variants. For example, determining which email addresses have access to the application, etc.
I was looking for a declarative way where, ideally, I only maintain a list of permitted email addresses and the "cloud run application" is only "magically" linked to this. With the result that only these users get access to the web application. That doesn't seem possible?
Ideally, the actual application should not be changed at all and an upstream layer would take care of the authentication and authorization, possibly in conjunction with the "Identiy Platform".
Best regards and any hint is welcome
Thomas
Let me add some sugar to this to better understand all these.
A Cloud Run application is packaged by you, you maintain the source code, if this is a website, placing a login button and handling authentication is your job to accomplish.
A Cloud Run system which is running all this on a hardware, it doesn't "look into" or handles your application code outside of the "code". Simply put it doesn't know if it's a Java or Python code and how to handle authentication out of the box for you - but read further.
If you require a simple way to authorize look into API Gateway it can be placed "before" Cloud Run. It might not be exactly your use case. These exists only for "API" designed services.
That upstream layer you need is the managed Identity platform, but the CODE should be assembled by you and deployed inside your Cloud Run service. The code will be the UI driven part, the authorization logic is handled by the Identity Platform so it reduces the amount of development time.
Your users would sign up using a dedicated registration page, and sign in by entering their emails and passwords. Identity Platform offers a pre-built authentication UI you can use for these pages, or you can build your own. You might also want to support additional sign-in methods, such as social providers (like Facebook or Google), phone numbers, OIDC, or SAML.
Look into some of the advanced examples to get a feeling how authorization can be customized further: Only allowing registration from a specific domain you could reuse one of these samples to maintain that shortlist of users that you mentioned.
In addition to #Pentium10's answer, you can also make all users authenticate to your app somewhat forcibly. (Imagine you're building an internal portal for your company, or an /admin panel for your app that only certain users/groups can access.)
This sort of use case can be achieved by placing Cloud Identity-Aware Proxy (IAP) in front of your Cloud Run service. That way, all requests go through this proxy that validates the caller. This is not like Identity Platform in the sense that visitors don't create accounts on your website (they use existing Google accounts or other IdPs like ActiveDirectory, or whatever you configure on IAP).
I have a little tutorial at https://github.com/ahmetb/cloud-run-iap-terraform-demo/ since IAP+Cloud Run integration is still not GA and therefore not fully documented.
I have built an API to my web application so that customers can access certain functionality without going through the dashboard. I have secured it by providing an API key to each customer that identifies them and restricts the IP address from which they can connect.
I have now had a request from a customer to allow them to access this API from their Salesforce platform. I don't know much about Salesforce, and when I asked them to let me know their IP address so I could create their API key, all they could give me was the list of reserved IP addresses published by Salesforce. This IP space is huge (millions), covering all of Salesforce, meaning that if someone gained access to the API key they'd be able to use it from any Salesforce account.
I have read some things about Salesforce having an OAuth service and having some kind of Application Connect service, but it mostly seems to be designed around allowing 3rd parties to connect to Salesforce - I'm getting a bit bogged down trying to determine if this is any use in my scenario (which requires authentication in the other direction).
I'd be grateful for any insight into whether there's something more specific I can do identify a particular Salesforce customer beyond simply putting dozens of CIDR blocks in my API key. I could ask my customer to identify themselves in the referer header when they call my API, for example, but of course that's trivial to spoof.
Thanks.
IPs can be spoofed too
Salesforce has a concept of "protected custom settings". You could make a "managed package" (Salesforce plugin, but you don't need to distribute it on their appexchange, Google Play/App Store equivalent), install it for the client and then enter the API key to the setting in a way that even client's sysadmins can't read it.
It'd be bit of work to set it up but might pay off if you think you'll get more customers on the platform.
How about a crude but effective iframe? or a link to your page they'd embed somewhere in their app?
Do you have just api keys? If you'd expose OAuth2 endpoint SF users could login to your app and then SF code could use access_token they got back instead of api keys. Or maybe you can protect access with certificate? Calling app would have to sign requests with a certificate. Client could upload it to their SF, you'd upload to your app...
You could demand the API calls to include the user's SF "session id" and you could use that to run some queries against source SF org. Org Id, user's login history etc things that are impossible to tweak even by sysadmins...
First of all, I apologize in advance for my naïveté on the topic.
I am trying to create a few microservices that are exposed using an API gateway. A few of these services will need credentials from Google account to access Google Calendar/Gmail etc.. is there any way for a user to only have to login once so that the credentials are all shared between the services? Or should only one service be facing the Google services with credentials?
It seems possible, you can ask a user to authenticate and authorize all permissions your application will need, all at once. But think about the user, when an application requires to access gmail, hangouts, photos, camera, etc. at once, the user normally disbelieve the application. So, the recommended approach is asking for the specific permission when the application requires it so that the user can realize each action you app do.
There exist many different ways to address your question depending on details, however the following link can help you to know where to start:
This link (Google Sign-in) has a wide context on all the Identity mechanisms to look for the most appropriate for you.
This another one explain all possible Identity mechanisms for specific use cases.
This authentication example for Google Calendar is useful, but this post explain how microservices authentication and authorization was solved.
Everything I'm reading shows that in order for an application to use onedrive, it has to do the oauth2 thing to get credentials. But what if you're a batch process and don't have a web interface for your users.
Google's API has a special type of account called a service account where once you set it up, you can control access to everything from that one account, no need to interact with users. Does such a thing exist for onedrive?
App-only authentication doesn't require the user be prompted for credentials but it also isn't supported in 100% of scenarios. For example, the APIs need a user principle for creating special folders and resolving a user's personal site. Also, it is only supported for OneDrive for Business, not Consumer. Consumer always requires the user be prompted for initial authentication.
Another option would be to spin up a web service of some sort that handles initial user authentication, ie. a sign up page. With that, you can retrieve a refresh token for offline authentication and store it for the user. Every authentication from then on can be done using the refresh tokens, which doesn't require a user prompt.
I finally found this. It's the same basic idea as google's service account, but I think it's harder to use. But at least the concept is supported.
http://blogs.msdn.com/b/exchangedev/archive/2015/01/21/building-demon-or-service-apps-with-office-365-mail-calendar-and-contacts-apis-oauth2-client-credential-flow.aspx