I’m coding a Firebase application.
The user can only read the database and the owner can write in the database to add some content.
The owner would need an admin desktop application to upload data on the database (storage and database).
Since the application is a C++ app I would use python to communicate with Firebase.
I wanted to use Pyrebase or python-firebase but unfortunately these projects seems not to support the new database Firestore…
The rest API could work but... only with the Firestore database part...
My only way to add content to Firestore and storage is then to use the admin sdk.
I know that the C++ applicaiton will be used only on the owner computer but I’m worried about getting the service account file.
What would be the best way to use safely the service account file?
I thought to:
Encrypt the file with a password and then ask the password every
time the c++ needs to use the admin sdk (which technology would be
better for this?)
Download the service account file everytime the app needs (but where
to store it safely in the cloud?)
In order to use the Admin SDK with a project, you must have access to the service account credentials for that project. And with those credentials, you have full and unlimited access to the project. You should only distribute the service account credentials to users who should have such access, typically the collaborators on the project.
For application level administrators that are not collaborators on the project, I typically recommend setting up an administrative dashboard with a server-side and a client-side component.
The server-side component runs in a trusted environment, which for me often is Cloud Functions, but can also be a server you control, or even your development machine. This is where you use the Admin SDK to perform application administration actions, which you then expose in an authenticated end-point that client-side applications can call.
The client-side component is what the application administrator uses. For me this is often a very simple web page, but it can also be any other technology you prefer, as long as it can call the end points you exposed on the server.
The key here is that the server validates that the user that calls it is authorized to do so, before executing administrative actions on their behalf. With this approach, you don't have to give the service account credentials to a non-collaborator, and can revoke the administrator's credentials if needed.
Related
I'm working on a project created using Identity Server 4 for authentication, an API application that handles all the data and business logic and a client web app.
The IdentityServer project uses a different database for managing the users of the app and the API project has a copy of that table that gets synced with the one from IS when the user logs in.
The problem I'm facing is this:
When a user confirms his email the information is handled by IS but until his first login, the user appears to have his email unconfirmed in the API project.
How can I solve this without coupling the IS project to the API one?
I see various way to handle this.
Use messaging system to sync data (Users and it't update) between both the database.
Access DBContext of API project into the IS to manage users.
Or even simply have api to give updates to API project upon first login.
I have an application that connects to firebase cloud storage to store images and firestore to store data. I have added some security rules that require the user to be authenticated to be able to modify the data. My application doesn't allow users to connect with firebase, I use another service so I made an automatic anonymous firebase authentication at the launch of the app so that users can use the application. I thought that the computer's SHA-1 key entered in the firebase(android) console would prevent the android application from being compiled on another machine and thus guarantee that anonymous users are on my application. However I can build and run the application on another computer without any problem, as if anonymous allowed that? How do I secure my application?
Thanks
The configuration data used by Firebase to find your project on the servers is not a secret (see here) and can be taken from your app by anyone and then used to also make API calls against your project. There is currently now way to ensure calls to the API can only come from your app (see here).
What you instead should do is create security rules that ensure all access is authorized, no matter where the API is called from. Doing this through Firebase's server-side security rules ensures that no one can bypass these rules, not even a malicious user.
Say that you give each user their own folder in Firebase Storage. You can then use security rules to ensure each user can only read and write files in their own folder. And with those security rules in place, it doesn't matter anymore whether they use your app to access the files, or whether they call the API with your project keys and their own code:, since the access is controlled by the server-side security rules.
I thought that the computer's RSA key entered in the firebase(android) console would prevent the android application from being compiled on another machine and thus guarantee that anonymous users are on my application.
That's not really the way it works. You can't restrict Firebase Auth from working on different devices or computers. The underlying REST APIs are public and can be called from anywhere on the internet. The SHA-1 key that you enter in the console is intended to identify your app, not a piece of hardware.
I am the owner of the Firebase project.
Is it possible (for accidental data manipulation reasons) to disable write access from Firestor DB?
For instance when login in the web admin console e.g.
https://console.firebase.google.com/u/0/project/MYPROJECTID/database/firestore
to not be able to write/update/delete any documents or collections.
If you want to disable write access to web and mobile clients, you can set the security rules to disallow all writes. There is no other configuration to control client access.
For backend code, and collaborators accessing the database through the Firebase console, you can only revoke access to any services accounts that might be used to make changes using IAM.
I developed two different Flutter applications. An Admin Version and another Client Version. I would like to use the same login (auth) and access to Storage for both Apps.
It's definitely possible to access the same Firebase project from two different apps. In fact, when these apps are locally part of the same "application", that is actually an intended use-case.
A few things to keep in mind though:
Firebase Authentication does not have the concept of an administrator user. It "merely" authenticates the user, allowing them to sign in with their credentials. Any administrator logic is specific to your application, hence often referred to as an application administrator. You'll typically want to flag application administrators, for example by setting a custom claim on their accounts.
Not all functionality that the application administrator may need is going to be available in Firebase's client-side SDKs. A common scenario is that the administrator should be able to create accounts for other users, where the client-side Firebase Authentication SDKs don't support this logic. For some more information on this, and how to solve it, see Firebase kicks out current user and my answer with many links here How to create firebase admin user for authentication in java. In a nutshell: you'll have to use the Firebase Admin SDK, in a trusted environment, for some of these operations.
You then secure access to Cloud Storage by writing security rules. For some examples of securing access based on the user, see the documentation on securing user data.
I have a legacy, monster software that is built around SQL membership. It isn't the most elegant code and sometimes the code goes directly into the database to pull users or roles out.
I need to migrate this to Active Directory. I'm thinking of authenticating against Active Directory, then saving the user on-demand into SQL. That way, the rest of the code works when trying to work with users, roles, etc against SQL. I would also have to plug the places where users are created and deleted.
Is it possible to authenticate against Active Directory via form authentication, but use SQL membership for the rest?
I'm sure what you ask is possible, but you may want to consider authenticating against ADFS instead of directly against Active Directory.
ADFS issues security tokens you can use to make authorization decisions. You can have it issue role claims into the token based on look-ups in a SQL attribute store. If your application is using things like IPrincipal.IsInRole to determine permissions, it should not have to change much.
Moving your application to token based authentication will make it easier to make your application internet ready (ADFS proxy) or trust issuers from other authentication domains (federation).