I have created a WPF application that connects to a SQL Server database directly (not through services), located on database server. Now I need to create user management, where each user will have its own log in credentials (not windows authentication). This is how I thought of doing it:
During the application installation, DB administrator will provide me with an account that contains enough permissions to create database
Using these credentials I will connect to SQL Server, execute a script to create database, and also execute a script to create one default admin user for this database, that will have full permissions.
I will use this new user to manage all users and roles for my database.
for each user in my application I need to create a user in my database.
Questions:
is this correct way of doing it?
I am confused about how to manage this. If I have a table Users and Roles in my database, and I also need to create users and roles on database level, then it looks like I am duplicating stuff?
Or I am missing something?
I would probably do it differently by creating roles and managing things through roles rather than user names/logins.
It would be better to create one application login in Database, whose credentials will be used for communication between your DB and application.
There is only very minor overlap. In your Users table you store the username that matches up with the SQL account, the username is the only overlap. All other information is stored in the Users table.
I don't see any problem with doing it this way, the only downside is that you are required to have an admin account with a considerable amount of access on whatever SQL Server it's installed on, but it sounds like you have already taken that into consideration.
Related
I have an application that accesses a database directly. This application controls what user can do according to the context.
At the moment, I am using Windows authentication, but all the users has permissions to select, insert, update and delete, because it is the application which controls the action.
For example, one user can modify a document, but only if the document is created by this user. So in the database the user has to have permissions to create a update, but only if it is the owner of the document. I am not sure if I can handle this case with SQL Server user roles.
But the problem is that all users have all the permissions to the database, so they could use another application, like SQL Server Management Studio, to access the database and do what they want.
So I was thinking in the option to use SQL Server authentication, with full access to the database. This user is not known by users, so they can't use another applications to modify the database.
The problem that I see with this solution is that I have to store the credentials in the client application, and I don't know if it is really a secure way to do it.
If using SQL Server authentication is an good option, how could I store the credentials of the user in a safe way?
I have read about application roles too, but it is needed to store the password in the client application, so I think I would have the same problem. And also I don't see the difference between application role and to use SQL Server authentication.
In summary, is it a good solution to use SQL Server authentication in the way I explained above? And if it is a good option, how could I store credentials in a safe way?
Thanks.
The difference between an application role and using SQL Auth is that the application role password is not enough, by itself, to access the database. The user must be individually authorized first and can be individually monitored and audited.
how could I store the credentials of the user in a safe way?
The application role (or SQL Auth) password is never truly secure when used from a client application running on a machine where the user is an administrator. So you could run the app in desktop virtualization, or a kiosk-mode PC.
But for many scenarios involving mostly-trusted users application role security is good enough, especially when combined with Windows Integrated auth so the users access to the database can be audited.
I have the project to create a C# application for multiple users. Users' credentials will have to be stocked in a SQL Server database table.This database will be used to stock further informations in other tables.
At an application user account creation, his level of permissions on the database will be set.
Knowing that the server/database login/users are already stocked in a system table in the database, can I use this table as my application credentials table too ?
In this case, could it allow to have a unique log for the application and the SQL server.
Thank you.
The short answer is yes but why would you want to allow users to access the SQL Server, that's the job of the C# application. The basic C# application template should be able to take care of the permission levels. These are generally stored in the aspnet database on your SQL server.
The safest approach is to have a single SQL user for each level of access, which can then be determined by the application, once the user has logged in.
You can easily log the who, what, when and why, by creating a simple logging method in C#, which records every SQL transaction.
(I would have put this in the comments but apparently my reputation isn't good enough ;-)
You might be able to do something like this, but I would advise against it. If it were me, I would do something like this (if I understand your scenario correctly, and just generally speaking....this is of course only one way)
Figure out the set of database access levels you want users to have
Create a sql user per scenario in sql server and add to the appropriate role to get the access required
Create an application role table with an ID column and the credentials for the sql users you created in step 2.
Create an application user table which stores user credentials and other information, including a role id which is a foreign key to the table created in 3.
In your application, when generating your sql connection/s, you can then use the application role details for the logged in user to create your sql connection string dynamically
is a good practice to authenticate using sql server logins?
for example, in an application, ask for username and password, and then try to connect to the database using those credentials? (maybe to retrieve user information), and then subsequents connections in the same way.
This way i have no need to store neither the user or password in the connectionstring, only the server and database information.
i know i must create a database user and login for each user, what is the downside of doing that way?
i apologize for my English is not native, also is my first post :)
thank you.
IMO, there is no problem until you give appropriate permissions to the user in the database server. For ex: application uses Northwind database but user is not given access or appropriate permissions to access the Northwind database, user will see exception. For this to work, we need to set impersonation to true.
To enhance it further create a AD group and give this group appropriate permissions on databases. Now, add users to this group to minimize errors while setting up each new user.
I am developing an accounting application using C# with SQL Server Express 2008, the application only accesses the database locally. i want the customer to enter a user name and password when he installs the application, that way he is the only one who can run the application, and my question is:
1. should i store the log in credentials in a local file, or create an sql server user account with those credentials and rely on the database keeping them a secret ?
2. if the second option is doable, how to do it from the installer package ?
There's a lot more to this.
If whoever installed sql server selected sql server security that user (sa) will have been defined and will have access to everything.
If windows only then it will be the windows user who installed sql server, and they will have access to everything
If Mixed, both will have access to everything
Then which user created the database on the server, they'll be dbo by default and have full access to their database.
So it all depends on who's doing what.
Does your app intaller call the sql server install?
Does it create the database?
Admin and dbo, can both grant access to said database to anyone they like.
Adding the windows user installing the app is simply a matter of getting your installer to execute a sql command or two. At that point you have Single Sign on. No need for password you are adding the windows user and mapping them to a database role/user.
If you want a username and password any user could use if they know it, then perhaps sql only / mixed mode is the way to go. Again a couple of sql commands executed from your chosen installer to caete user fred password ?, job done.
The point to remember is in order to execute the instructions to add logins and users, roles etc, you need to connect as someone else with permission to do that, e.g. windows admin or sa.
Also most application users on managed networks do not have admin permissions, so you could have a bit of fun round that as well.
I suggest you have about of a read about sql server security, there's a few ways to skin this cat, only you have enough info to choose the best option.
You might even want to have a think about application based security, if each install of your application creates it's own database and role....
You could do something like, store database settings, such as IP, Port, Username and password login attempt credentials locally, perhaps in an XML file, but then store the login credentials for the program in the database.
Note: Obviously i don't know how much you know about security, but here's a few tips:
1)Don't store the password directly in the database. Use a hash and some method of encryption.
2)Check the hash of a given password a user attempts to log in with, with the database stored variable you created for the program, which should also be a hash.
Basically, at no point should the database know what the actual password is, only a given hash that you passed it, and can compare to in the program itself.
With regards to the database access, I would create a user which has access to only the schemas you want it to. From there, get the logged in user in your application / program to log into the database with the credentials in, for example, an XML file. It's also an idea to encrypte these details in the XML file too, so they can't be tampered with locally.
my c#.net winforms application which uses sql server 2005 express , would be run by three users, & i want to give different user id & passwords to each of them, so in this case which security feature of SQL SERVER should i use?
application roles --can application
roles be used for this, or do
application roles provide only one
credential for the whole
application?
create a table for userids &
passwords
create new logins for each user to
connect to sql server and grant
permissions to each login
my application would be installed on 3 machines, server-SVR , Clients-c-1,c-2. all on LAN with windows xp.
can i create multiple application roles for a single application? i mean that if i have 3 forms in the application. can all 3 forms use different application roles ?
You could create roles in SQL Server, let's say YourAppSuperRole, YourAppNormalRole, YourAppReadOnlyRole, and then grant object permissions to each of those roles, e.g. grant insert on sometable to YourAppSuperRole. or grant select on sometable to YourAppReadOnlyRole. Then, however you create users in your database, whether they be SQL Server users or domain users, you add the user to the appropriate role. That's how you'd implement security on the database objects. How you handle the GUI/presentation-layer experience can be disconnected from the back-end. You could identify the Windows domain user, or create application users and require logon using those users, and then govern the GUI behavior accordingly. E.g. you might remove the SAVE RECORD button from the user who you've placed in the Readonly role.
EDIT: I think the simplest way would be to use the Windows domain user. Grant db access to the domain users in the back-end, and add those users to the appropriate back-end roles (to determine what they can see/change in the back-end). Then, in the GUI, adapt the graphical behavior to the domain user who is using your app. If you didn't remove the Save button from the form, the readonly role user could click it but the update would fail. So you'd typically not offer that user the apparent capability to do things they lack permission to do.
My guess is you want to have different users run the application with different roles (permissions and abilities and access to features in your app).
I wouldn't use SQL Server security to give them different "application roles". Just define one server user for your application. Then use some way of identifying the user (NTID, or login using some username/password table you have in your database) and use that to configure their experience in your application.