Thread: DB Authentication Design
Hi all, I'm thinking that all apps that connect to the database should have their own user. For example, the web application processis one user, then a report builder process should have another user, and a different process that imports data shouldhave his own too, and so on. Would you generally agree with that? I'm thinking that by having different users, PGbouncer can create different pools, and better allow me to control concurrency. Thanks! François
Attachment
Hi all,
I'm thinking that all apps that connect to the database should have their own user. For example, the web application process is one user, then a report builder process should have another user, and a different process that imports data should have his own too, and so on. Would you generally agree with that?
I'm thinking that by having different users, PGbouncer can create different pools, and better allow me to control concurrency.
Thanks!
François
On 12 Jan 2014 22:31, "François Beausoleil" <francois@teksol.info> wrote:
>
> Hi all,
>
> I'm thinking that all apps that connect to the database should have their own user. For example, the web application process is one user, then a report builder process should have another user, and a different process that imports data should have his own too, and so on. Would you generally agree with that?
>
Should be a good security design given you restrict access and ability for each usrer. E.g. reporting user will not need update privileges, you can have an additional application admin user who will be used for applying db patches (only that user should have alter and create privileges).
> I'm thinking that by having different users, PGbouncer can create different pools, and better allow me to control concurrency.
You can restrict this and also restrict other resources e.g. work_mem( probably reportjng user will need higher than others).
Regards
Sameer
PS: Sent from my Mobile device. Pls ignore typo n abb
Hi all,
I'm thinking that all apps that connect to the database should have their own user. For example, the web application process is one user, then a report builder process should have another user, and a different process that imports data should have his own too, and so on. Would you generally agree with that?
I'm thinking that by having different users, PGbouncer can create different pools, and better allow me to control concurrency.
On Sun, Jan 12, 2014 at 6:30 AM, François Beausoleil <francois@teksol.info> wrote:Hi all,
I'm thinking that all apps that connect to the database should have their own user. For example, the web application process is one user, then a report builder process should have another user, and a different process that imports data should have his own too, and so on. Would you generally agree with that?
I'm thinking that by having different users, PGbouncer can create different pools, and better allow me to control concurrency.It really depends on what you are doing, what your security model is, what your concurrency constraints are, etc. What you are describing is a fairly typical approach and it sacrifices some real security possibilities for connection pooling possibilities. The fundamental question is whether the security of your application's user should be tied to the database connection.