4 ms·

That's exactly what we do in LedgerSMB. More to the point, the db user credentials are application login credentials so the application has the db permissions

That's exactly what we do in LedgerSMB. More to the point, the db user credentials are application login credentials so the application has the db permissions of the user. No password? The app can't access any data. Now this has some significant tradeoffs. It is very much a good decision for an ERP app. However for customer portals we are looking at a different approach, namely: 1. A portal user account in the db with very restricted permissions (and no direct access to tables) 2. A portal back-end user account in the db with limited access to tables and which owns most of the security definer functions the portal uses. I see no reason why we might need dynamic SQL in such functions, so no avenues for SQL injection unless you can exploit a trigger or something. For fine-grained permissions, the functions could do additional permission checks based on an auth token. This should effectively prevent SQL Injection from being particularly useful in this context.

krallin 13y ago
Under this model, how do you store user (database) credentials?
- einhverfr 13y ago
  The application logs into the db with the credentials the user supplies, so the problem is not our problem anymore. This means, btw, that you can hook up LedgerSMB to use LDAP Auth simply by changing PostgreSQL's LDAP settings. Here's an example howto, using LDAP via Samba (I would prefer Kerberos, but this demonstrates what people can do with such a model): http://cocnm.computerisms.ca/index.php/Install_Ledgersmb http://cocnm.computerisms.ca/index.php/Install_Ledgersmb Now, again, this is great for an internal business tool. It may not be what you want for a high-scaling public web app. We use a different model for customer portals (with security again encapsulated in the db, but through a different way). It's worth noting btw that PostgreSQL allows you to specify auth method by connecting host and requesting user/database, so you have a high degree of control over what sorts of connections can be enabled or disabled in such an environment in the db backend.

krallin 13y ago

Under this model, how do you store user (database) credentials?

einhverfr 13y ago
The application logs into the db with the credentials the user supplies, so the problem is not our problem anymore. This means, btw, that you can hook up LedgerSMB to use LDAP Auth simply by changing PostgreSQL's LDAP settings. Here's an example howto, using LDAP via Samba (I would prefer Kerberos, but this demonstrates what people can do with such a model): http://cocnm.computerisms.ca/index.php/Install_Ledgersmb http://cocnm.computerisms.ca/index.php/Install_Ledgersmb Now, again, this is great for an internal business tool. It may not be what you want for a high-scaling public web app. We use a different model for customer portals (with security again encapsulated in the db, but through a different way). It's worth noting btw that PostgreSQL allows you to specify auth method by connecting host and requesting user/database, so you have a high degree of control over what sorts of connections can be enabled or disabled in such an environment in the db backend.