Hello,
I believe Windows auth is the best practice to use to connect to SQL DB. I am hear talking about application user account..
Is it true that SQL auth is only great for multiple role apps and window auth is only good for single role app? I never heard that windows auth with muitple role os only good for smaill internal app? multiple Windows logins = multiple connections = no pooling = poor scaling?
The problem with using Windows auth for a web application is that many web applications store their application users' credentials in the same SQL database that is used for other application data.
So you have a chicken-and-egg problem. You can't authenticate the user before connecting to the database, and you can't connect to the database without authenticating the user.
It should be possible to use Windows authentication, and then also have application-specific attributes of the user stored inside the database. But most people find this cumbersome to administer, and also limiting to portability of the application.
For example, if one of the feature of the application allows users to change their own password, then the process running your web application needs the privilege to alter a Windows password, which may mean that the application needs to run with Administrator privileges.
If you let the application manage user ID for the context of the application, then to change a user's password is just an SQL operation, and your application is in charge of enforcing security for that.
I'm not sure what you mean by single-role and multi-role app. I have built apps before where there are multiple SQL Server Database Roles, each with a Windows Domain Group of users allowed in that role. So user management is completely within Active Directory, with a 1-1 correspondence between the Domain Group and the Database Role.
We typically did not manage the security within the application itself except obviously declaratively during the database creation where each object was granted access by particular roles according to the design. Typically, in a simple case, we relied on db_datareader role being granted for general usage to non-specific groups of users like database and network administrators for troubleshooting or report-writers or business analysts for ad hoc reporting. Actual users of the app would be granted execute on the relevant SPs to be able to modify any data (so all data creation or modification was through SPs and only explicit members of the ThisAppsUsers AD group could do it). Any advanced SPs (say, merging or deleting accounts) would only be accessible by ThisAppsAdmins AD group. And that was usually all we needed for moderate-sized applications. For more complex functionality, it was also possible to interrogate AD directly for custom attributes (user is an admin only for this customer account but for others is just a user)
This same technique can be used with SQL Server logins, but of course the individual SQL Server logins have to be added to the database roles, and you don't have the richness of AD and have to build some kind of directory service into your database.
The ability to even use AD may not be possible for many applications, so in that case, the security architecture would obviously have to cater to that model.
using the integratedSecurity=true option for SQL JDBC , by including the JDBC auth .dll, should give you database connectivity without authenticating...