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
Related
I have a Windows application project that uses SQL Server 2012 for maintaining it's data.
For securing my app, I decided to create a SQL Server login for every user in my system.
Is this a good idea?
If you're not using Windows Authentication then this will be your best bet. You could also place Users into Roles and specify permissions for that User group.
If you require that each user has different permissions and you you need to be precise as to which user has what permissions to each database entity (table, view, stored procedure, function etc) then creating a new user will be the way to go. This will allow to you fine tune each account,enable/disable accounts, grant/revoke permissions easily.
As #dash states it will be harder to maintain, but I think having the granular level of security outweighs maintaining a large number base.
You could try creating an access matrix table to map data access levels to each user. Then, you can show/hide the data loaded in your application depending on the access level of the signed-in user. As #dash said, this will be harder to maintain but it may well be an easier option than creating individual logins. Secondly, I suppose it would also be easier to create an insert/update/delete script to edit the matrix rather than have a DBA edit the SQL Server logins.
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.
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.
I want to create logins & users for my c#.net winforms application which uses sql server 2005 express .& upto my knowledge i have built these steps.
So , I want to ask that are these steps correct or am i making a lot of mistakes.
Also, if am missing any step then please add new steps.
Also, in the last step, what should i do, do i have to grant permissions to both ,USERS & SCHEMA, OR to only USER, OR to only SCHEMA.
I am seeking improvements in this model or a new model if anybody can provide. Would be a great help.
I want to GRANT & DENY permissions of DATABASE LEVEL such as CREATE, DROP, ALTER DATABASE ; of TABLE LEVEL such as INSERT , DELETE, ALTER, UPDATE & of COLUMN LEVEL.
Also, is creation of schema necessary?
As far as i know:
CREATION OF LOGIN is necessary
CREATION OF USER for the above created login is necessary
CREATION OF SCHEMA is or is not necessary? i don't know.
I'm changing my whole answer. I really think it's not a good idea to grant uses direct login access to your db. The DB is not the right "choke point" for permissions. Create one user with the total db permissions you will need. Then grant the users features in your application based on their role in the application (tracked in a table in your database).
There are a lot of problems with creating 1 login per user in your database. A few are 1. Maintainance nightmare 2. Now your users can log in to your db directly if they can get connected to it with Management studio or some other tool.
To elaborate . . . create one login for your application. Name it something like MyApplicationUser.
Create a table in your application to track the roles that each user could be part of. This can also track the features they are allowed to have in your application (though probably in a different table)
When the user starts the application, the application is opend using the same db credentials (MyApplicationUser)
Now you know who the user is (based on NTID, or application login), and you can give them the features that are appropriate to them in the application)
I have written some C# which connects to a live production database. I want to give my application read only access to the DB but am unsure how to achieve this.
Is there any trivial way to get this done by amending the connection string?
My understanding is that the application will logon with the credentials of the person running the application and hence may or may not have write access to the db based on that fact. Can I statically limit the permissions of the application so that if someone changes the program to do something devastating at a later date any manipulation will fail?
Apologies for how trivial the question may be but it's my first venture into the world of MS programming.
Thanks,
Gav
You can't change the permissions for the account by changing the connection string. There is a user account in the database that determines the permissions.
Unless you want different people to have different permissions, you should set up an account for the application and use in the connection string.
For any account in the database you can specify which databases it can access, and what it can do with the databases. The permissions can be specified down to the level of objects and operations, so you can for example specify that it can only do selects on certain tables.
Have it login to the database server as a user that only has read-only permissions. That and just don't try to write anything to the database.
You can always grant the user connection to your database just the "db_datareader" role on that database.
db_datareader gives your user SELECT permission on all tables - but nothing more.
There are basically two main types of SQL Server authentication:
Integrated Windows authentication and
Mixed authentication mode (SQL Server authentication)
It sounds like you are using the former. If you use the latter you can create a specific user account within SQL Server, give it a username and password, and then grant access to the tables you wish it to be able to read. You can control at the account level what access it has to any object in the database.
See http://msdn.microsoft.com/en-us/library/ms144284.aspx for more details.
Just a thought; usually not every logged in user gets to access the database, let alone a read-right. Therefore you in your case you can create a database user for your application with read rights; and use that in your connection string.