Just got a task to create clien-server system (no more specification yet) but I am sure there will be some kind of user login needed. All I can think of now is just DB based login, if the user is a DB user with e.g. read rights, it will let him continue. Is there any other built-in solution suitable for that?
try to manage users from the application (add a table called users in your DB) don't let users access to DB permissions!!
you can use windows Authentication, or you can authenticate users using NTLM if they your targeted users are located inside the LAN, which is more secure, there is a best practices check the following links
http://support.microsoft.com/kb/301240
http://www.asp.net/mvc/tutorials/older-versions/security/authenticating-users-with-windows-authentication-cs
http://www.codeproject.com/Articles/94612/Windows-Authentication
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.
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.
The client I work for at the moment wants to use their Active Directory logins with single sign-on when connecting from a domain computer. I have however no experience with Windows Authentication.
The problem however is, that I need to reference the users in the database. Also, the users already should be in the database even if they haven't logged on yet. (Guessing I'm syncing with active directory with LDAP every night??) The reason for that is that other users should be able to assign the user to specific tasks.
See the following basic diagram:
My question is:
Should I use a MemberShipProvider or just extend IPrincipal?
Am I thinking the right way by syncing every night?
How can I prevent the user data is fetched from the database every request?
Use membership provider to connect to LDAP for you, then authenticate with the ValidateUser method in the provider.
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 have a WPF application and a SQL Server database with a Users table. Every user has it's own row including hashed password and role in Users table.
I need to let them authenticate in my application and keep some kind of credentials, including role. Based on that role, they will see only what they should see.
Can you give me some clue how to accomplish it? What is the best way to keep those credentials and hide parts of my application based on user's role?
Thanks for any help, JiKra
Ok, I was thinking and how about to use a singleton? User authenticates, I grab his role from database, instantiate a singleton, set his credentials and use them in my app.
Is that correct? It's the easiest way to do that?
JiKra
The "functional model" as you call it can be based on the MembershipProvider/RoleProvider APIs. There's a tutorial video by Todd Miranda:
http://windowsclient.net/learn/video.aspx?v=293710
What the tutorial lacks is where you should store the information so that it's available for the other parts of the application. The answer is simple - since you have the stateful application, you can store the information in a shared (static) resource in a class.
Please also be aware of a potential security risk, I've added a comment under your question.