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.
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 am making a website in asp.net. In my application, I divided the users into two categories. One is normal users and other is admin users. Admin users will be probably one or maximum two users. I decided to create separate two database users for admin users rather than table users in SQL server. So I have three database users two for admin and one for normal users
Case 1:
Scenario is that if normal user want to login. System will connect to normal database user in SQL SERVER and will look the credentials in users table. If it found the user then session will generate and normal user will redirect to welcome page.
Case 2:
For admin users I have direct database user. I am not storing and looking admin users in users table. Admin user can be dynamic. I don’t want to save database user in connection string in web.config file for admin. Connection always be runtime but the problem is how to handle database users credentials because I don’t want to store database user credentials in cookies and session.
Suppose if admin usr 1 login through login page. My system will check either that database user exist in SQL SERVER or not. If exist system will redirect to welcome page and I want my whole application remember admin usr 1 is logged in.
How to handle this scenario in asp.net.
I would look at implementing ASP.NET Identity rather than rolling your own security implementation. Far better to use a tried and tested methodology and, having just recently implemented this in a project, it is fairly straight-forward if you read through some of the tutorials on the web.
All users should authenticate through a standard login page regardless of their permissions. Once authenticated you should control their access to your application via their Roles, which you can create and assign depending on whether or not the user is a "normal" user or an "admin" user.
You mention about Admin users having a different SQL account with which to connect to the database, I would question whether this is necessary as you should be able to control the actions that each user can perform by the security applied to each user that logs in to your ASP.NET application.
I would recommend to not have different databases for your roles, because it can mess up the business logic. Instead make one database with a user-table and then have a role-table that connects through a FK.
Background
I'm building a single tier application Winforms application using C#. A SQL Server localdb database is attached to the application that runs when the application does. The plan was to use Windows Authentication to verify that the user is part of the MyApplication role/group and can use the application. But, in order to prevent users from accessing the database via other means, I was thinking of using an Application Role so that only the one SQL application user can edit the db tables.
Question
My understanding is that in order to use an Application Role, you need to provide a username and password in the connection string. I can encrypt this information, but obviously it will need decoded before being sent to the database. Is this a concern in a single tier application? What are other alternatives?
To use an application Role, you'll use the sp_setapprole stored procedure where you will provide the name of the application role and the password, rather than sending it in the connection string. When you use application roles, you still connect using an ordinary login, but once you successfully sp_setapprole, your connection loses its user permissions and instead gains the permissions of the application role. Having the decoded password in memory is a concern if you have reason to believe that users may decide to use a debugger to attach to your process to extract the password. Any administrator would also be able to decrypt the encrypted password on disk as well if you choose to use windows machine-level key containers. Using only a single tier for an application that uses a database is a security risk, and you have to decide based on the circumstances surrounding the application whether it is an acceptable risk to gain the reward of skipping a few weeks of design and development.
Source:
https://technet.microsoft.com/en-us/library/ms190998(v=sql.110).aspx
I highly recommend implementing a web api to manage your application's interactions with the database as well as security. This web api could use a windows "service" account to authenticate with the database, and users would authenticate with the api using their individual windows accounts. This has the added benefit of you never having to think about passwords. As far as managing API permissions, that is an issue that is up to you to design and implement as you see fit. The main issue you need to understand and deal with is uniquely identifying AD users. Take a look at this SO post for more info on that: What Active Directory field do I use to uniquely identify a user?
Your service account would have all necessary permissions on the database to do what the application needs to do, but not all api users would necessarily have permission to use all api functions. You would manage a store of uniquely identified AD users that have permission to use the application and what permissions they have. The rest is design and implementation details that are up to you.
Define user with privilege only to execute stored procedures. By this way if someone use SQL Management Studio, s/he cannot browse/edit tables and even cannot see the table names.
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.
Is it possible to hide the databases used in my application from the user.
What I need is that when user opens SQL Server management studio, he should not see the databases used in my application developed in C# and VB6
There are 2 ways to forbid access to db content:
Encrypting db content : will decrease performance
Autorisations: you create a user specifically for your application, put it as db owner, and remove access for all users. And also you need to disable Windows Authentication connection in MsSQL server, so that admin cannot connect this way.
Accessing the database with a user login only gives access to the databases for which that use has been given permission. Different users have access to different databases. Perhaps you have 3 users: root, admin, user.
As a start point, try looking at
http://msdn.microsoft.com/en-us/library/ms187936.aspx
You would need to revoke the permission 'VIEW ANY DATABASE' from the role PUBLIC (SQL SERVER 2005 onwards).From Stackoverflow. For more details see a ans Hide SQL database from Management Studio
Don't grant the user permission to access the database. Instead embed credentials in to your program that allow it to access the DB via a dedicated account. When the user uses your program the program's user is granted access, but if the user tries connect directly he is denied access.