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.
Related
We have a native Windows desktop app that uses resources that we control on behalf of our customers. In the vein of not rolling our security infrastructure I am wondering if it makes sense to use an OAuth library / framework like IdentityServer (our frontend and backend stacks are .NET based with ASP.NET Core on the backend).
But from what I have read OAuth is all about giving an application access to resources that the users owns that are managed and controlled by another party without exposing the user's security credentials to the application.
Given the application is from our point of view "trusted" it seems more straight forward for the application to capture the password directly from the user and obtain an access token (e.g. bearer token) from directly from the back end rather then redirecting the user to the web browser.
Management of authorization levels for various resources is something we need to take care of robustly, as we will have multiple applications and users which will need configurable access levels to different types of resources, so I don't really want to be rolling our own solution for this.
We also want the ability for users to remain logged for indefinite periods of time but to be able to revoke their access via a configuration change on the back end.
Should we be using a different type of framework to help ensure our implementation is sound from a security point of view? If so please any suggestions of suitable technology options would be most helpful.
Alternatively, is there a OAuth flow that makes sense in this case?
It sounds like the "Resource Owner Password Credentials Grant" might help with your problem.
In the short term, the use of oauth may not seem very different from the normally "username password + rbac" based model, but the benefits may come in terms of scalability later on, for example when single sign-on needs to be implemented, or when it comes to the need to provide service interfaces to third parties.
I am using HERE api in both frontend and backend. If I try to put my app_id and app_code into the frontend code, it will be available to anyone seeing my site.
I can try to create a domain whitelist and put my domain in this. But still, if I set the HTTP header "Referer" to my domain, I am able to access the API from any IP.
So, what do I do?
The Difference Between WHO and WHAT is Accessing the API Server
Before I dive into your problem I would like to first clear a misconception about WHO and WHAT is accessing an API server.
To better understand the differences between the WHO and the WHAT are accessing an API server, let’s use this picture:
So replace the mobile app by web app, and keep following my analogy around this picture.
The Intended Communication Channel represents the web app being used as you expected, by a legit user without any malicious intentions, communicating with the API server from the browser, not using Postman or using any other tool to perform a man in the middle(MitM) attack.
The actual channel may represent several different scenarios, like a legit user with malicious intentions that may be using Curl or a tool like Postman to perform the requests, a hacker using a MitM attack tool, like MitmProxy, to understand how the communication between the web app and the API server is being done in order to be able to replay the requests or even automate attacks against the API server. Many other scenarios are possible, but we will not enumerate each one here.
I hope that by now you may already have a clue why the WHO and the WHAT are not the same, but if not it will become clear in a moment.
The WHO is the user of the web app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
OAUTH
Generally, OAuth provides to clients a "secure delegated access" to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server.
OpenID Connect
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
While user authentication may let the API server know WHO is using the API, it cannot guarantee that the requests have originated from WHAT you expect, the browser were your web app should be running from, with a real user.
Now we need a way to identify WHAT is calling the API server, and here things become more tricky than most developers may think. The WHAT is the thing making the request to the API server. Is it really a genuine instance of the web 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 It can be one of the legit users manipulating manually the requests or an automated script that is trying to gamify and take advantage of the service provided by the web app.
Well, to identify the WHAT, developers tend to resort to an API key that usually is sent in the headers of the web app. Some developers go the extra mile and compute the key at run-time in the web app, inside obfuscated javascript, thus it becomes a runtime secret, that can be reverse engineered by deobusfaction tools, and by inspecting the traffic between the web app and API server with the F12 or MitM tools.
The above write-up was extracted from an article I wrote, entitled WHY DOES YOUR MOBILE APP NEED AN API KEY?. While in the context of a Mobile App, the overall idea is still valid in the context of a web app. You wish you can read the article in full here, that is the first article in a series of articles about API keys.
Your Problem
I can try to create a domain whitelist and put my domain in this. But still, if I set the HTTP header "Referer" to my domain, I am able to access the API from any IP.
So this seems to be related with using the HERE admin interface, and I cannot help you here...
So, what do I do?
I am using HERE API in both frontend and backend.
The frontend MUST always delegate access to third part APIs into a backend that is under the control of the owner of the frontend, this way you don't expose access credentials to access this third part services in your frontend.
So the difference is that now is under your direct control how you will protect against abuse of HERE API access, because you are no longer exposing to the public the HERE api_id and api_code, and access to it must be processed through your backend, where your access secrets are hidden from public pry eyes, and where you can easily monitor and throttle usage, before your bill skyrockets in the HERE API.
If I try to put my app_id and app_code into the frontend code, it will be available to anyone seeing my site.
So to recap, the only credentials you SHOULD expose in your frontend is the ones to access your backend, the usual api-key and Authorization tokens, or whatsoever you want to name them, not the api_id or api_code to access the HERE API. This approach leaves you only with one access to protect, instead of multiple ones.
Defending an API Server
As I already said, but want to reinforce a web app should only communicate with an API server that is under your control and any access to third part 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 defence as what you are protecting is worth.
For an API serving a web app, you can employ several layers of dense, starting 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 the 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 these 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 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 these solutions require constant monitoring to validate that the false positives are not blocking your legit users and that at the same time they are properly keeping at bay the unauthorized ones.
Summary
Anything that runs on the client side and needs some secret to access an API can be abused in different ways and you must delegate the access to all third part APIs to a backend under your control, so that you reduce the attack surface, and at the same time protect their secrets from public pry eyes.
In the end, the solution to use in order to protect your API server must be chosen 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.
So using API keys may sound like locking the door of your home and leave the key under the mat, but not using them is liking leaving your car parked with the door closed, but the key in the ignition.
Going the Extra Mile
OWASP Web Top 10 Risks
The OWASP Top 10 is a powerful awareness document for web application security. It represents a broad consensus about the most critical security risks to web applications. Project members include a variety of security experts from around the world who have shared their expertise to produce this list.
I am building a web application with front-end coded in angular. The front-end will access a bunch of web-services coded in Java/Spring. There might be other ways that people may try to access the webservices such as from a desktop tool. Now I need to secure the whole infrastructure.
I need a way to maintain a user repository, i.e. provision users and manage users, roles etc.:
users should be able to register themselves and have their emails verified.
admin should be able to approve users and assign them roles, delete users, update them etc.
I also need single sign on functionality. So once you login through the webfront end, you should be able to access the REST based webservices seamlessly (depending upon the role you have).
I do not need to support millions of users, so something light-weight will be preferable.
I am looking for open-source solution(s) that can:
allow user management (ideally over REST based API and have its own user interfaces as well)
allow single-sign-on functionality for web frontend and webservices, and potentially for desktop apps that may need to be implemented.
I have tried Apache Syncope which seemed promising as it provided REST based APIs. I am thinking of using it with CAS. However, the default UI seemed kludgy and CAS doesn't directly support REST.
I am looking at Shibboleth and OpenIDM as well - but none seems to be meeting my requirement directly.
I'll appreciate any suggestions on what options/stack can I consider for this. Ideally, a single solution or a well integrated solution on Java/Spring stack might work better for me.
you should have a look at https://github.com/openMF/mifosx for Java and Springs RESTFull Web service.
and https://github.com/openMF/community-app for there AngularJS web app.
plus you can also find a live demo link on there repository.
username is mifos and
password is password.
it is ment for microfinance but you can study its architecture implementation and use there core functionalities, it is really amazing.
I am in need of advice on how best to tackle the following scenario and best practices to implement it.
Our company wants to overhaul its old IT systems and create new website app(s) and possibly mobile apps down the line for its employees and contractors to interact with.
So i was thinking about creating an api that both the website apps and mobile apps could be created from...
https://api.company.com/v1
The advice i need is in relation to security/authorization of the api. My thoughts at present in how to implement this would be that the employees/contractors would interact with the api through the companys website app(s)/mobile apps which would then communicate with the api and set the appropriate access permissions
WebsiteApp.company.com ->>> api.company.com/v1
mobileapp ->>> api.company.com/v1
First thoughts is just setting up a username and password for each user on the api side and let both the websiteapps and mobile apps use this. The problem however is that the contractors and possible some employees cannot be fully trusted and could pass on username and passwords to third parties without the company's permission. So my question is really what other security/authorization/authentication strategies should i be looking at to overcome this situation. In a perfect world each user would have to authorize each device/mobileapp/websiteapp he/she wants to access the api from...
Is OAuth 2.0 capable of this?, not sure if its capable of specific user/device/website scenario though ?
Technologies thinking of using are:-
API
Node.js with (Express js? or Restify?) , MongoDb
Consumer Apps
Website Apps (Angular Js, Backbone etc..)
Mobile Apps (PhoneGap, Jquery Mobile etc..)
Many Thanks
Jonathan
It seems that your main concern is that you can't trust the people you are giving access to, and if this is the case, you probably shouldn't be trying to give them access in the first place. If these apps are to be used for any confidential information or intellectual property that you are worried about someone else seeing if the contractor/employee gives away their password, then you have to consider the contractor/employee just taking the information and giving it away.
In this situation your username/password should suffice for authentication, however you should also consider very tight permissions on who can access what. If you are worried about information getting out, everything should be shown on a need-to-know basis. If a contractor doesn't need a specific piece of information, make sure it isn't provided to his account.
You could also consider tracking the locations (IPs) that an account is being accessed from. Perhaps when an account is accessed from a new location have the employee/contractor complete some task to validate the account; which could be anything from entering a validation code (similar to a two-factor authentication), to calling a help-line and having the location authorized.
This might be a bit late, but as i am going through the same process (What is the correct flow when using oAuth with the Resource Owners Passwords Credentials Grant)
We have not figured out the core implementation what you want to do sounds similar to what we are trying to do for our service.
From my understanding it depends on the apps and if they are trusted or not and what you plan to do with your API moving forwards. If the apps are trusted you could potentially use HTTP-Basic over SSL which is a viable solution.
For us, we are going to create a suite of trusted official apps (Web, Mobile etc) via the API and then open it up, so we are deciding to go through the pain of oAuth2 where for our apps we will use the Resource Owners Passwords Credentials Grant type where you swap a users user name and password for a token which is what the client will use to interact with your API with the trust implicitly defined.
When we open up the API for 3rd party consumption this model wont work and we will go through the processes that all the major sites do and get explicit permission from the user on what the 3rd party apps can do with their data.
We're trying to evaluate a solution to implement "true" SSO for multiple (already existing) web solutions. True SSO here means to login on any service, and be authenticated on all, without further actions from the user.
All of the applications we're going to use support OpenID and/or have plugins that allow OpenID, so this seems like something worth looking into. However, as I understand OpenID, the users would still be required to enter their OpenID credentials in each service.
Is there a sane way to implement SSO with automatic login once the OpenID provider has authenticated the user?
In an earlier project, we hacked up the PHP session data in the login procedures of two applications (both running on the same domain and server) so a login in the first application creates the session data for the other application as well. However, this is a very hacky solution and is prone to break when either application is updated, so we're trying to avoid it this time.
Are there any other SSO solutions that we could look into?
i am assuming that you have the control on the SSO implementation
there are some things you can do to make sure that once the user has been recognized by the SSO application, he will virtually automatically be logged in to your other applications
in your SSO application, create a whitelist of service providers. authentication request from those websites will be automatically approved. thus, user won't be asked to approve the request manually
in your application, set the return_to parameter as the page the user is intending to immediately open. don't simply set the return_to to that application homepage
by the way, the most standard openid implementation accepts any url. however, if you want to use the sso in a controlled environment, you can set the service provider to have a whitelist of trusted identity providers. after all, it's the service provider which initiated openid authentication.
Yes, there is a means to do this. Run an Application Server, Node Based, and register cross-domain techniques to offer cookie-credentialed (backed up by site-handshakes as each new user arrives, to scale better and minimize resource expenditure per-session).
I am working on such a beast right now, and I'm 5/6th done.
I have taken care of several annoying variables up front- including the means to assure unique user logon- and I've taken a stand on other issues- one just can't get everything done in one system. However, one can have a true SSO if one is willing to pull out some stops. It is YOUR stops which will define your solution. If you have not accurately portrayed your limitations then there isn't a solution which can be offered for implementation here, and the nature of your problem is ENTIRELY implementation- not theory. In theory you have 4-5 different options. In practice you will find your answers.