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.
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 building an application using azure mobile services, where I have used azure authentication services for user authentication. Each user can store some of their information. I want to add more than one admin who can manipulate the information of all user when needed. I also want to provide admins a separate front-end. Is it possible to implement. If possible kindly provide me some resources.
Mobile Services on it's own doesn't have any concept of what an Admin is in your application. For that reason, you'd have to design the admin system yourself. You can do this in a few different ways including:
Create an Admin only app that the admin's use and send the Mobile Service Master Key over in the headers. This will make the user.level property return "Admin" while user's who are just authenticated to your app will have a user.level property of "Authenticated". You can use this in your server scripts to basically say "If admin, do THIS, otherwise if authenticated, do THAT".
You can create a Role table in your database and check if the user making the request is an admin for reach request. If so, you can then use similar server side logic above to perform specific logic for the admin vs the non-admin.
If you know the specific user IDs of people who will be admin's, you can just check against the user making the request in your server side logic (the advantage of this approach is that it doesn't require an admin only app or an additional check against the database to see what the user's role is).
Again, Mobile Services doesn't have a concept of an admin as far as your users go (only the sense that if the Master Key is sent in the request is "from an admin") so that's something you have to put in place yourself.
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.
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.
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.