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.
My problem is that I want to get deployment information from Github for headless devices. The devices only have ssh & can call REST API. I.e. they do not have git for example.
There are a number of existing solutions:
Deployment keys – Requires git executable to be installed and I need to also access Github Container registry
OAuth App – Tokens have are associated with a real user while the devices are owned by an organization. And having a shared ghost user account has many drawbacks. This would work perfect if the tokens could be owned & managed by an organization.
Github App – Installation tokens expire after an hour, normal tokens after 10 mins. This means I need a highly reliable server process to create the tokens on the fly and the device is more complicated.
Since deployment keys & OAuth apps use tokens that can be revoked instead of time out, I am curious why this feature is unavailable with Github Apps? After all, for headless devices they just now force you to create a server that authenticates the device and creates a temporary token. This seems more error prone than if they had a long term token with revocation?
Am I missing something?
I'd like to add the ability to create JIRA issues from within a Unity game (C#), such as for submitting player feedback and bugs. I see various authentication approaches, from "basic" auth (just a raw UN and PW) to an Auth Token approach, to possibly some OAuth-based approach which I don't yet understand.
I've set up JIRA integration in web projects over the years, and it was fairly simple. I never had concerns over authentication, since the credentials to access JIRA were always stored within the web server's configuration. But with a deployed application (such as a game created in Unity), I don't understand if there's any secure/correct way to provide credentials to the application. It seems that it would be trivial for anyone to either inspect the code, or the memory of the running application, and extra the authorization credentials.
Is there a secure way for a desktop application (not connected to a central server) to authenticate against an API like JIRA's?
I have some difficulties with automating log in process in the web application. It's an angular app, I'm writing tests in protractor. The app uses Azure AD, so I need to pass e-mail, password and the verification code from mobile app. I know there're some very useful libraries to generate the code. The problem is I don't have the access to Azure admin panel so I'm not able to get the secret key that is necessary to use those libraries. Is it possible to somehow skip or mock the MFA? I'd be grateful for any advices how to solve this.
Assuming you want to run these tests on the CI, you could hard code a test user credential in your web application that returns true when used in a specific environment. Lets say you want user xyz#abc.com to login and then perform other tasks, add code in your web application so that when xyz#abc.com sends a request with dummy secret key, log the user in. Then you'd have to mock all the rest of the APIs that your application uses.
You can also remove the auth when you are testing it in a test CI environment. This would be a good solution but tricky. You would have to remove auth entirely for all APIs and that would require design pattern change etc.
But get the access and do it the right way.
I would actually recommend NOT skipping MFA on E2E tests in your CI.
By setting up a bypass in your code related to your environments you are taking the risk of having this "test account" in the production environment and being it found by someone. And believe me, it will happen sooner or later ;).
Today multiple third-party tools exist allowing you to parse SMS-based MFA or TOTP codes (like the Azure app). For example, the GetMyMFA platform provides you with an API allowing you to receive and inject in your CI your MFA codes.
If you have the time and resources, I would recommend looking for a tool that allows you to get MFA codes from an API and have your automated E2E tests inject that code in your CI.
Cheers
Building a multi-tenant application. The tenancy of the application is organizations and each organization can have multiple projects.
As user authentication, implemented OAuth based authentication and role-based authorization.
Example
Let's assume our service serves images to the user applications and naming it imagebox server.
Now a user can register with our application. First, he needs to create an organization and then he can create multiple projects in an organization.
In a project, he can create an image with the following properties
Name of the image
Description
Upload an image ( It will automatically create a URL)
The customer on imagebox server, will create App Keys. Though we need only one app key per project. Though, he should be able to create multiple app keys as well delete the previous one whenever needed.
Now customer of our image box, download the SDK from the imagebox server. They write their application over the SDK and pass the APP key.
ImageBoxClient client = ImageBoxClientBuilder.build(APP_KEY);
The client should be able to access images of the project corresponding to the API key.
Questions
Is there any difference between API keys and App Keys?
How to handle Authorization - How to restrict only N:1 mapping between API key and project, a project can have multiple API keys but a key should belong to only one project?
How to achieve authorization in the above case (restrict key to the project), if I intended to use identity management solution like Azure AD?
How to achieve authorization in the above case (restrict key to the project), using API gateway?
Assumption
From your question its not clear if the client SDK's are mobile applications or not.
My answer will be based on the assumption that they are SDKs for mobile applications, but even doing so, a lot of what I will say it's still applicable for SDKs that aren't for mobile applications.
The Difference Between WHO and WHAT is Accessing the API Backend
As user authentication, implemented OAuth based authentication and role-based authorization.
User Authentication will identify WHO is accessing the API backend, but will not identify WHAT is accessing it on its behalf, and you are thinking in using an API key to identify the WHAT part.
So to better understand the differences between the WHO and the WHAT are accessing an API server, let’s use this picture:
The Intended Communication Channel represents the mobile app being used as you expected, by a legit user without any malicious intentions, using a genuine version of the mobile app, and communicating directly with the API backend without being man in the middle attacked.
The actual channel may represent several different scenarios, like a legit user with malicious intentions that may be using a repackaged version of the mobile app, a hacker using the genuine version of the mobile app, while man in the middle attacking it, to understand how the communication between the mobile app and the API backend is being done in order to be able to automate attacks against your API. Many other scenarios are possible, but we will not enumerate all possible ones here.
So the WHO is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows. The WHAT is the thing making the request to the API server. Is it really a genuine instance of the mobile app, or is a bot, an automated script or an attacker manually poking around with the API server, using a tool like Postman?
For your surprise you may end up discovering that the WHAT may be one of your legit users using a repackaged version of the mobile app or an automated script that is trying to gamify and take advantage of the service provided by the mobile application.
API Keys
For a project, there will be a unique app key using which SDK authenticate and identify the project.
So I think you want to say here that you will use an app-key or api-key header to identify WHAT client SDK is accessing the API backend in a per project basis, and this seems to be reinforced by:
Is the API key is the right solution, then how to restrict only N:1 mapping between API key and project, a project can have multiple API keys but a key should belong to only one project.
In my understanding the client SDK will need a specific API key per project, thus if it needs access to more then one project it will need to be released with one API key per project it needs access to.
While this may be useful to filter down and identify access to each project, I want to call your attention that it cannot be trusted as the only way to restrict access to them, and I hope that by now it's easy to see why, because you have already read about WHO vs WHAT is accessing the API backend? If not please go back and read about it.
Anything that its shipped into a client SDK must be considered public, and if you have shipped secrets with it, you need to considered that they are now compromised, because an SDK can be reverse engineered by de-compile it, or a MitM attacks can be performed to understand how it communicates with the backend, and instrumentation frameworks can be used during run-time to hook on the running code, and change its behavior, and/or extract data.
Extract an API key with Reverse Engineering
You can learn how to do it by reading my article How to Extract an API key from a Mobile App by Static Binary Analysis, and see how easy it can be done.
Using MobSF to reverse engineer an APK for a mobile app allows us to quickly extract an API key and also gives us a huge amount of information we can use to perform further analysis that may reveal more attack vectors into the mobile app and API server. It is not uncommon to also find secrets for accessing third part services among this info or in the decompiled source code that is available to download in smali and java formats.
The above article have a companion repository, that shows one of the most effective ways of hiding a secret in an mobile SDK, by using the JNI/NDK:
JNI is the Java Native Interface. It defines a way for the bytecode that Android compiles from managed code (written in the Java or Kotlin programming languages) to interact with native code (written in C/C++). JNI is vendor-neutral, has support for loading code from dynamic shared libraries, and while cumbersome at times is reasonably efficient.
Extract an API key with a MitM Attack
In the article Steal that API key with a Man in the Middle Attack I show an easier way to extract an API key, or any other secret, from a mobile app, and performing the MitM attack is made easy by using a tool like MiTM Proxy:
An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.
Instrumentation Frameworks
A more advanced technique is to use instrumentation frameworks, like Frida or xPosed to hook into code at run-time, and change its behavior or extract the secrets from it.
Frida
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
xPosed
Xposed is a framework for modules that can change the behavior of the system and apps without touching any APKs. That's great because it means that modules can work for different versions and even ROMs without any changes (as long as the original code was not changed too much). It's also easy to undo.
So if your are storing secrets in the keys-tore of your device, an attacker just needs to poke around the code until he discovers the method that retrieves the secret from the vault, hook on it at runt-time and extract the secret without changing behavior, therefore staying under the radar. The extract secrets can then be sent to a remote control server, that will launch automated attacks against the API, just like if it was the WHO and the WHAT the API is expecting.
Defending an API Server
Depending on your budget and resources you may employ an array of different approaches and techniques to defend your API server, and I will start to enumerate some of the most usual ones, but before I do it so I would like to leave this note:
As a best practice a mobile app or a web app should only communicate with an API server that is under your control and any access to third party APIs services must be done by this same API server you control. This way you limit the attack surface to only one place, where you will employ as many layers of defense as what you are protecting is worth.
You can start with reCaptcha V3, followed by Web Application Firewall(WAF) and finally if you can afford it a User Behavior Analytics(UBA) solution.
Google reCAPTCHA V3:
reCAPTCHA is a free service that protects your website from spam and abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive challenges to keep automated software from engaging in abusive activities on your site. It does this while letting your valid users pass through with ease.
...helps you detect abusive traffic on your website without any user friction. It returns a score based on the interactions with your website and provides you more flexibility to take appropriate actions.
WAF - Web Application Firewall:
A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. A WAF is differentiated from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws, such as SQL injection, cross-site scripting (XSS), file inclusion, and security misconfigurations.
UBA - User Behavior Analytics:
User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.
All this solutions work based on a negative identification model, by other words they try their best to differentiate the bad from the good by identifying what is bad, not what is good, thus they are prone to false positives, despite of the advanced technology used by some of them, like machine learning and artificial intelligence.
So you may find yourself more often than not in having to relax how you block the access to the API server in order to not affect the good users. This also means that this solutions require constant monitoring to validate that the false positives are not blocking your legit users and that at same time they are properly keeping at bay the unauthorized ones.
Regarding APIs serving mobile apps a positive identification model can be used by using a Mobile App Attestation solution that allows the API server to verify with a very high degree of accuracy, that the requests are coming from WHO and WHAT is expected.
Conclusion
My recommendation is to use defense in depth, where you use as much techniques as you can afford and in accordance with the value of what you are trying to protect and the legal requirements for that type of data, like the GDPR regulations in Europe.The end goal is to increase the expertise and time necessary to overcome all defenses, to the point that the attacker may give up and move on to easier targets.
So defending an API server is a daunting task, and and never ended battle.