I have a backend system built in AWS and I'm utilizing CloudWatch in all of the services for logging and monitoring. I really like the ability to send structured JSON logs into CloudWatch that are consistent and provide a lot of context around the log message. Querying the logs and getting to the root of an issue is simple or just exploring the health of the environment - makes CloudWatch a must have for my backend.
Now I'm working on the frontend side of things, mobile applications using Xamarin.Forms. I know AWS has Amplify but I really wanted to stick with Xamarin.Forms as that's a skill set I've already got and I'm comfortable with. Since Amplify didn't support Xamarin.Forms I've been stuck looking at other options for logging - one of them being Microsoft's AppCenter.
If I go the AppCenter route I'll end up having to build out a mapping of the AppCenter installation identifier and my users between the AWS environment and the AppCenter environment. Before I start down that path I wanted to ask a couple questions around best practice and security of an alternative approach.
I'm considering using the AWS SDK for .Net, creating an IAM Role with a Policy that allows for X-Ray and CloudWatch PUT operations on a specific log group and then assigning it to an IAM User. I can issue access keys for the user and embed them in my apps config files. This would let me send log data right into CloudWatch from the mobile apps using something like NLog.
I noticed with AppCenter I have to provide a client secret to the app, which wouldn't be any different than providing an IAM User access key to my app for pushing into CloudWatch. I'm typically a little shy about issuing access keys from AWS but as long as the Policy is tight I can't think of any negative side-effects... other than someone flooding me with log data should they pull the key out of the app data.
An alternative route I'm exploring is instead of embedding the access keys in my config files - I could request them from my API services and hold it in-memory. Only downside to that is when the user doesn't have internet connectivity logging might be a pain (will need to look at how NLog handles sinks that aren't currently available - queueing and flushing)
Is there anything else I'm not considering or is this approach a feasible solution with minimal risk?
Related
BACKGROUND INFO
I have developed an application in R through the shiny package, and deployed it online through the shinyapps.io service.
Among its different functions, the shiny app can send emails (through my personal Google Account) to users if the fill a form. The emails are sent through the functionalities of the gmailr package, and to make it work I had to follow the procedure on the Google Cloud Platform to create a JSON token, configure the OAuth consent screen, and store the credentials I obtain in a folder of my R project. All the steps to this process are reported at the end of this GitHub issue I opened a while ago.
THE PROBLEM
The JSON token I generated on the Google Cloud Platform expires after some days.
After googling around, I noticed that this can happen if my "Application", on Google Cloud, is still in the Testing phase. First question about this statement:
What does it mean when Google refers, on the OAuth screen, as an Application in Testing phase? My application is already online on shinyapps.io, it's already functioning, and when I create a new token it can also send emails correctly (for a while).
In addition, on the Google's OAuth consent screen, I now have the possibility to "publish" such application. If I do that, the status changes as In production, and this message is displayed. Other questions:
What does it mean that the application will be available to everyone with a Google account? My application deployed on shinyapps.io doesn't require any login or any other data from the users, then what is this app they're talking about?
What will happen to users that try to connect to my application?
Are my credentials, as for example the JSON file, safe?
I know that there might be a lot of confusion in this post, but I am relly not an expert in this field, and so I am worried to make some mistakes.
Thanks a lot for your help!
The GMail API, OAuth and all, is typically meant to allow your app to send email on behalf of any user. It seems your use-case is a little different - you only ever need to connect one user: your own.
What does it mean when Google refers, on the OAuth screen, as an **Application in Testing phase? My application is already online on shinyapps.io, it's already functioning, and when I create a new token it can also send emails correctly (for a while).
I think you mostly answered this yourself in your further questions. Google thinks you're building an app that any GMail user can connect to, and so for security reasons, they want to differentiate between a test app and a production app. They don't necessarily know whether or not your app is published on shinyapps.io.
What does it mean that the application will be available to everyone with a Google account? My application deployed on shinyapps.io doesn't require any login or any other data from the users, then what is this app they're talking about?
I alluded to this earlier, but the GMail API is intended for apps that allow any GMail user to connect and manipulate their own email. Imagine a third-party email client, or similar. Again - Google's wording sounds a bit odd wrt your app since it doesn't fit that bill.
What will happen to users that try to connect to my application?
If you don't explicitly host your own server that implements OAuth with Google, then nobody can even try to connect. As long as you don't leak the shared secret from your Google Cloud Platform entry, you're safe.
Are my credentials, as for example the JSON file, safe?
Probably anyone with the JSON file can send email on your behalf. Marking your app as 'in production' will not change the security implications of your JSON file.
Unfortunately, Google has pretty tight security around their APIs nowadays. If you want to mark your app as "in production" you might open up a can of worms regarding "restricted scopes" (sending email counts as restricted). However, since you're using the JSON file instead full OAuth, I'm not sure if this applies to you. To my knowledge, you should be safe to try marking your app as "in production". Worst-case scenario, you might be able to weasel around the strict verification requirements by saying your app is "internal":
Internal Use: The app is used only by people in your Google Workspace or Cloud Identity organization. Note that your app will not be subject to the unverified app screen or the 100-user cap if it's marked as Internal.
I am looking to make an app that would have its Backend on another service like AWS or some other. This app would be having many features and functionalities.
But for chat feature, I am exploring options and wondering that would I be able to integrate Firebase in my app.
I have read about Firebase Functions to add more functionality at the backend and also the installation of Firebase Admin to servers.
But still I am not convinced about their capabilities and exactly what all I can do with them.
It would be great if someone who has experience with Firebase help me out figuring if going with it is the best case for me or is there something else I should look into.
So first you can't use Firebase in combination with AWS or Azure etc. Firebase is based on Google Cloud and is the interface between the mobile client (the running app on the client's smartphone) and the backend (your Firebase project).
What I use is, for example, Firebase Cloud Messaging, to simply notify one or multiple users by trigger an HTTP Request from my own web server.
I also made some apps to store the data in FireStore or in the Realtime-Database, so that I don't have to set up a whole new infrastructure. And this is basically the goal of Firebase that you can simply start with your app, without carrying about that.
So what I've heard about Firebase is that you currently cannot install Firebase on a server of your choice and you have to use Google Cloud.
Hopefully, you can do something with my answer. If you have further questions feel free to ask them.
Is it possible to set up Firebase to allow Auth/DB access into a common/shared database instance - where that instance is setup to be a centralized storage location for some 3rd party service?
For example, let's say there's an analytics service called StackOverflowAnalytics.com .. and so anyone who signs up for that service, can add tracking to their app with some secret user key. And then all the tracking for that Key is pushed to the same Firebase DB instance. And then the user can login via Firebase auth and the rules will restrict that they can only access the node for their Key.
I'm working on a 3rd party analytics client for Android - along the lines https://mint.splunk.com - where I would like to provide users a small Java/Android library they can add to their Android project, and this will help them track different data points while their app is running. The data is made accessible by saving it to the cloud from the device.
I am currently using Firebase, but it seems in order for the Firebase Auth & DB of a given Firebase instance to be accessible - the "specific app signing key" (package name/etc combo) needs to be set in the console for that Firebase instance.
It seems sharing across across unknown apps is not possible on Firebase. And that if I want to support something like that with Firebase (and not have to go to another cloud storage option), then I need to set up some proxy REST client .. like in Java or PHP .. that can serve as a centralized access point to that Firebase instance. Just wanted to check with other folks first in case this has been encountered and perhaps there are best practices already established around this particular case. Thanks
Firebase client libraries are generally not meant to be repackaged for use in other libraries. They're meant to be used at the app level.
A unique SHA-1 key is required on Android for Authentication to work with a particular app identified by package name. This requirement will definitely become a problem for you if you want this to work with arbitrary apps, since you would have to manually enter one for each app that wants to integrate.
As far as I know it's not possible to do what you want without creating a proxy, as you mentioned. I assume that firebase has some app validation that make unfeasible to share the Auth/DB.
Maybe a solution for you is to make a proxy too to access data:
"It looks like in order to access Firebase Analytics data, you export it to BigQuery. This is working for me and is automated."
I am considering to migrate an application to Cloud Foundry since I'm tired of managing my server on my own. In my current application I use Spring Security and sessions to handle my user logins. I am however clueless on how to change my code so Cloud Foundry's multiple instances support my user logged in in a somehow stateless way (but using a token). I have looked into UAA, but it seems that this is for cloud foundry users, not users of my application.
Something OAUTH2-like seems to be a solution, but it seems I would have to rely on third parties if I want to do it in a developer-friendly way. The Cloud Foundry (or Pivotal Web Services in this case) documentation is also quite unclear on the matter.
When looking at the Spring Cloud documentation, I do find information on how to use OAUTH2 providers like Github to do things like Authentication, but it doesn't show how to actually use the Principal or how to handle stuff like Authorization (role-based).
I assume there are ways to run my own OAUTH2 service, and that would be the recommended solution, but again, there's quite a lack of documentation.
Can anyone give me some pointers?
A couple of key questions here are where is your user store currently? And what do you want to do with it moving forwards?
If you manage your own users and wish to continue doing so then, after migrating your users to the appropriate backing service and updating your app to be able to bind to that service using CFs VCAP_SERVICES env variable (also see spring cloud), our session affinity should allow you to push your app pretty much as-is. Otherwise a little further discussion is required.
Does this help:
https://docs.cloudfoundry.org/devguide/deploy-apps/prepare-to-deploy.html#sessions
Cloud Foundry supports session affinity or sticky sessions for incoming HTTP requests to applications if a jsessionid cookie is used. If multiple instances of an application are running on Cloud Foundry, all requests from a given client will be routed to the same application instance. This allows application containers and frameworks to store session data specific to each user session.
How would you use Firebase's simple login to allow users to upload music files.
As I understand it, it doesn't make sense to even think about storing audio files in Firebase's database which is why I would like to be able to store them on an external PHP server.
So, the question revolves on whether I can use Firebase's simple login system to allow users to authenticate to an external server.
I have seen Using NodeJs with Firebase - Security ... which gives some great insight, but then how would you enable the large file upload to the external server?
The technique from the answer you linked will work for your situation too, you just need to translate it into PHP and the Firebase REST APIs. Additionally, since the REST API isn't real-time you must add some kind of task queue that it can poll.
Your program would flow something like this:
User logs in to Firebase with Simple Login
User write to only a place that they can (based on security rules). The user also writes an entry into a task queue.
Your PHP server connects with a token that allows reads of all of the user's secret places.
Your PHP server polls the firebase every once in awhile to look for new tasks. If there's a new task, it validates the user and allows that user to post data to it.
All that being said, this is going to be pretty complicated. PHP's execution model does not lend itself well to real-time systems, and
I strongly recommend you consider some other options:
You're using a cloud platform, Firebase, for your realtime stuff, so consider a cloud service for your binaries too, like filepicker.io
If you really want to host the files yourself, use something that's more real-time like node.js. It'll save you the effort of constructing that task queue.