Sorry for may be simple question. I not experienced with server-based apps developing.
I study Azure recently and create simple mobile application that connect to azure database. Its make some trivial operations on tables like add items and make SQL select queries. Now I want add authorisation to app and restrict some operations with tables in db based on it. What is best way to do it? I think it's a good idea to write backend on azure server with authorisation-based rules but I don't find out about it from Azure documentation. For example what I want to achieve:
Not authorisation mobile app user restricted to make any modifying operations and can select only predefined columns.
Authorisation user can make add/update operations on some tables based on user info(uid/login etc...).
If I create database rules on frontend(mobile app) side its not difficult to write another app that have possibility to make anything with database in bypass of my app. Isn't it?
If I create database rules on frontend(mobile app) side its not difficult to write another app that have possibility to make anything with database in bypass of my app. Isn't it?
This is very true; security shouldn't be (just) in the frontend. Make sure your backend is set up in such a way it checks the access rules each time someone tries to do something in the backend.
Now, as far as your question goes: please implement an API that connects to your database. With each and every client directly connecting to your database, you will lose all control. If you implement an API in front, you can do stuff like caching and asynchronous processing if you need to.
When implementing the API, you can have the GET methods be unsecured, while POST, PUT and DELETE use a (for instance) JWT token retrieved from Azure Active Directory. This repo and the presentation it links to might give you some reference.
Related
What is the best way to restrict the scope of a connected app to a set of objects? My current solution is to use the Manage user data via APIs scope but that still grants more access than required.
A solution I see frequently is to create a user with a restricted profile and connect with that user but then you lose context of actions made by users in the connected app so this solution doesn't work
Tricky, you typically don't. (consider posting on https://salesforce.stackexchange.com/, there might be a clever way I didn't think of).
You can flip the connected app from "all users can self authorise" to "admin-approved users are preauthorised" and then allow only certain profiles / permission sets to use the app. But the bulk of it is "just" enabling the connection via API and cutting it to say Chatter only or OpenId identifiers. And that's already an improvement compared to SOAP APIs where you don't have scopes and the app can completely impersonate the user, do everything they can do in UI.
Profiles/permission sets/sharing rules are "the" way even in not immediately obvious situations like Lighting Connect Salesforce to Salesforce or Named Credentials access to another org.
If you can't restrict the visibility with profiles and access to all tables user can see is not acceptable...
you could create series of Apex classes exposing certain queries, updates etc and grant profile access to these classes - but without full api access? You could even let them pass any SOQL (evil) but use with sharing, WITH SECURITY_ENFORCED, stripInaccessible + custom restriction on tables before returning results
you could look into https://developer.salesforce.com/docs/atlas.en-us.238.0.apexref.meta/apexref/apex_class_Auth_ConnectedAppPlugin.htm although I suspect it's run only on connect, not on every request. So at best you could deny access if user has right to see some sensitive data, not great
if there are few objects you need to block updates if done via app - Quiddity might be the way to go. Throw error in a trigger if action started from REST context?
give the Transaction Security trailhead a go. If it looks promising (there's way to check "application" and "queried entities" according to this) - might be a solution. You'll likely have to cough up $ though, last time I checked the cool bits of event monitoring & transaction security were hidden behind an extra paid addon (standalone or bundled with platform encryption and Field Audit Track into Salesforce Shield solution)
2 logins? dedicated user for querying stuff but inserts/updates running as your end user?
I am working on a project that allows a user to create a user to create app keys or secrets so that specific services can be used by external clients. A user can create multiple secrets that they can choose to use across multiple clients.
For this I am planning to create a decoupled auth server that will use identityserver4.
What really holding me back is that I am not sure whether or not I should create an API layer at the auth server. The reason I am considering API at auth server is so that I can create sort of an admin portal client that will give the users a front-end for creating, renewing, and accessing their app keys/secrets. Even the admin portal is going to be a de-coupled angular application.
There are two things that are holding me back at the moment:
I am not sure if it's a good or safe idea to serve this data via
an api layer. From what I understand, identityserver will not be able to provide functionality that allows me to access a list of a user's clients through an endpoint but please correct me if I'm wrong and there's a better way to approach this.
I know we can easily create new clients and persist it into the database with identityserver4 and I am planning to use ClientCredentials grant types for user clients, but is there a link at the database and identity level between a user and a client? Or will I need to create that functionality by myself?
So far I've looked but I have not bee able to find examples that are similar to my situation with identityserver4
Sorry for the noob question, I am just getting into identityserver and web security in general so many of these concepts are still very new to me.
For number 1, I would say yes you can create an API layer to server data. If you check the IdenttiyServer4 AdminUI, Rock Solid has also use the admin API behind the UI. But you must consider encryption, TLS and other security mechanism to keep this safe.
AFIK for number 2, there are no links at identity level between a user and a client. You have to create that by yourselves.
Basically, you need a system that supports Multitenancy. I have achieved that by adding a TenantId field in the AspNetIdentity user table. And also added the tenant Id to claim list.
Please do not hesitate to correct me if i am wrong.
I have been following your project for quite some time now and am intrigued by the functionality of gunDB where it doesn't require a database in between and keeps security in check.
However, I've got some questions about GunDB which I've been thinking about for quite some time now before I can give Gun a go with a project I'm currently working on. In this project it is necessary that data is safe but should also be shareable once a group has been setup. The project is a mobile app project and ata is mostly stored on the device in a SQLite database.
I have been looking into Gun as it allows for better usage of the app in sense of collaboration. The questions I have, however, are:
User authentication
How is user authentication handled through private keys? So how can a user "register" with, for example, a username and password to login to the service.
For authentication I am currently using Firebase where it is possible to use username/password authentication and I would like to know how Gun approaches this case and how it's implemented.
Data storage
In the documentation and on the website it's stated that data is stored locally with every client and can be stored on a "node" or server using either a local hard drive or the Amazon S3 storage option.
What I am curious about is what data is actually stored at the client? Is this only the data he/she has access to or is this a copy of the whole dataset where the client can only access whatever he/she is granted to have access to?
Maintaining your data
When I've got a production system running with a lot of data, how will I be able to manage my data flows and/or help out my clients with issues they have in the system?
In other words, how can I make sure I can keep up with the system if I want to throw in an update and/or service my clients with data issues.
My main concern is the ability to synchronize their local storage correctly.
Those are all my questions for now.
Thank you very much in advance for providing some clarity on these subjects.
Best regards,
(Answered by Mark Nadal on Github: https://github.com/amark/gun/issues/398#issuecomment-320418285)
#sleever great to hear from you! Thanks for finally jumping into the discussion! :D
User Authentication,
this is currently in alpha. If you haven't already seen these links, check them out:
https://github.com/amark/gun/wiki/auth
http://gun.js.org/explainers/data/security.html
https://github.com/amark/gun/blob/master/sea.js#L23-L43
https://github.com/BrockAtkinson/login-riot-gun
If you have already, would love to either (A) get you to alpha test and help push things forward or (B) hear any specific questions you have about it. This thread is also a more at length discussion about alternative security API ideas: #321 .
Data storage.
Browser peers by default store the data that they subscribe to, not the full data set. You could ask it to store everything, but the browser wouldn't like that. Meanwhile NodeJS peers, especially if hooked up to S3 or others, would store all data and act as a backup.
Does this make data insecure? No, encryption should keep it secure, even if anybody/everybody stores it, the encryption makes it safe. (See [insert link to (1)] for more information).
Maintenance.
You would service your customers by deploying an update to your app code. It would not be ideal for your customers if you could meddle with their data directly. If they wanted you to do that, my recommendation would be that they change their password, give the new password to you, and you login and make any necessary changes. Why? Because if you have admin access to their data, their privacy is fundamentally violated.
I have a database with all my employee's information. Should I build an API or should I give direct access to the database?
The API could be built with Node.js and be a REST API. The database access could be given with different database users / different permission sets.
I'm confused because when I query an API, I usually get JSON data back which is awesome. So I wonder if only I can build an API that contains all the data I want and when I query it, I can have my employee's info back in JSON format.
There are reasons to use a REST API. For example you'll have a app, that will be available to the public, you might don't want to write your SQL queries directly in your code, as well as the credentials to connect to your server. Anyone with the knowledge could decompile your app and see your code and have access to the credentials to you database server. The good approach here is to write an REST API to handle the flow of data between your app and database, since REST API should be designed to be accessed publicly, you'll only have to pass in the data, or just call the api you need, you don't need the servers credentials to connect. If you are going local, then you could use the database approach of yours. Since your app will be used only by your clients.
Is it possible that a website uses the models of another lavarel website to access the database, without the first website having the sql credentials hardcoded. But with the credentials to log into the second lavarel website hardcoded.
This way the first website doesn't have to have the sql credentials on it's ftp server, but can still access the databases through the other website (with their personal login of that website).
If that is impossible, I am wondering, is there a way to access a databases without having to hardcode the credentials anywhere.
UPDATE (the actual problem)
Only a part of the database should be visible to a particular user, so i can provide different users with different credentials and they all see something different in the database
What you are talking about is an API. So you'd build out the entire infrastructure on the first website, then on the second website, it would make some kind of calls to the first website to get back the information it needs, usually using some kind of credentials or access token.
This way, you can allow anyone in the world to communicate with your website, kind of like how Facebook, or Twitter does.
As far as accessing your database, you would need to tell your app somewhere the credentials to use, so technically, you do need to hardcode them somewhere as they can't just magically make up some credentials somehow to access a database.
if your different users are defined:
use laravel model/db event to replicate the data to a database by
user.
Or sync each database with a cron job..
These have benefits to avoid security transport problems.