I have a small web application in asp.net and I'm using SQL Server. How do I authenticate my web application to block some people from changing the database?
This statement has to change from this:
Data Source=AYKUT-PC;Initial Catalog=BUS;Integrated Security=True
To something like this:
Data Source=AYKUT-PC;Initial Catalog=BUS;Integrated Security=False
Integrated Security is a feature that allows SQL Server to authenticate a user based on their Windows login.
You could also use SQL Server authentication, which would require a specific user name / password to login.
Finally - you could use Mixed mode that would allow both SQL Server and Windows authentication.
Here's an article about it: http://technet.microsoft.com/en-us/library/ms144284.aspx
If you would like a more detailed answer about how to implement it - you should probably give more information about your situation, and what your requirements are.
EDIT:
SQL Server can restrict permissions to users (or SQL Logins). So you could restrict acccess to certain tables through a combination of authentication methods and security permissions.
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 a desktop application in .NET Core. I will connect this application to an Azure SQL server. The information that will pass between the two is very sensitive. Each query to the database can return a response of a few kilobytes to 4 MB. When executing queries on the SQL server I would like to know the login \ identity of the user making the request so that I can return only the data this user is allowed to see.
I am trying to decide between connecting my desktop application directly to the Azure SQL database or creating Web APIs.
My Questions Are:
Which would you recommend, connecting directly to the Azure SQL Database or using a Web API that connects to the database on the server?
I know it is bad practice to hard code the user name and password to the SQL server in my application. If I connect directly to the SQL server would I have to create an account on the SQL server for each user and ask the user for their credentials when they login and then pass it to the SQL server?
If I use a Web API how do I obtain the users credentials? Again, do I have to set up individual accounts for each user? Would I do this using OAuth or some other method? https://learn.microsoft.com/en-us/aspnet/web-api/overview/security/individual-accounts-in-web-api
Would anyone endorse using WCF Data Service instead?
No, this is a potential security risk if you make your SQL Database publicly available. There is an identity provider for ASP.NET Core you can decide weather you want to store the users in the DB or you can also use external login providers like Facebook, Google, or Microsoft.
If you want to do this, you should use Azure Active Directory Authentication you can use it to authenticate users for your application and for the Azure SQL Database both. But, this can work if you do B2B applications, or and internal app for your company. If you want to have a public application available on the internet, and let everybody to register you should go with the first solution.
It is described in the identity provider for ASP.NET Core article.
You can't, if you check the Choosing between .NET Core and .NET Framework article, it says "WCF server implementation is currently only available in the .NET Framework" only the client is implemented in .NET Core.
I am writing a small addon mobile app to an existing applications database, the application stores login details through SQL Server logins:
I want to be able to use these existing logins (and permissions if possible) in my mobile web app but I can't find if there is an easy way to do this.
I was hoping there would be an existing provider that would allow me to do this via the web.config.
Is there any way to do this without having to code all the login/authentication manually?
eg:
<providers>
<add name="SQLProfileProvider" type="System.Web... />
</providers>
Alternatively does anyone know of any resources that could help me do it manually?
Please don't judge to harshly if I'm being an idiot, this is my first foray into asp.net!
Update:
Maybe it wasn't clear what I am trying to do so I will try and expand.
I have an existing desktop application (not under my control).
It uses SQL Server 2008 to store it's data and it authenticates users using SQL Server Logins.
I am writing a web app to connect to this database.
I want to allow users to log in to the web app with their existing login details from the desktop application.
eg. I have a database with the user 'abc123':
I want to be able to use this login within asp:
I know this is possible using my own membership provider within MVC but if this has already been written I would love to be able to use an existing membership provider.
Does anyone know if this membership provider exists?
The question is interesting in fact. I've never heard of an out-of-the-box membership provider that directly uses sql logins. So, my answer is 'no that doesn't exist'.
I can't imagine it would be terribly difficult to write however. Just implement the MembershipProvider (http://msdn.microsoft.com/en-us/library/System.Web.Security.MembershipProvider(v=vs.110).aspx) and run sql scripts for all of the 'CreateUser' stuff. It should work in a very straight forward manner.
I would just note that this is a very non-traditional use of the db logins. But I see how you would instantly get the benefits of any permissions applied to the users/roles setup in the database. This is not very scalable, but you would have very granular permissions in place.
Maybe a more scalable solution would be to have a users table mapped to generic logins that represent certain types (e.g. ReadOnlyLogin, WriteableLogin, etc.) That way you may have 100 users, with usernames and passwords in a table, and then have them assigned to a particular dblogin (mentioned above). When a user logs in, you would then use the given login whenever they accessed the db, enforcing any permissions set on the login. So, Bob, Frank, and Harry would use ReadOnlyLogin, and Sally, Jane and Samantha would use WriteableLogin. Just a thought.
I need to use a Windows application running on remote clients that will connect to a web service. The web service will access an SQL database to verify users, and roles, and perform other tasks. I am using ASP.NET Membership to manage the users and roles. I have ASP.NET Membership, and the web service working on the development machine. I have a windows client with a service reference that works when I access methods that do not access the database, but when I try to access a service method that access a database method I get The user is not associated with a trusted SQL Server connection. I get various permissions errors depending on what I am try to fix this, but this is the gist. I don't want the Windows client to need DB permissions. I want it to send a user name, and password to the web service, then the web service wraps Membership.ValidateUser(userName, password)
Can someone tell me how to set this up?
You should consider setting up SQL Server to use SQL and Windows Authentication (mixed mode). It's most likely running in Windows Authentication mode only. You can take a look at this link to get started.
It sounds like, by the way you have it designed, is that you would have to set up an account for each user. In my experience it's best to just create a specific SQL account with the necessary permissions, and have each client use that account. You could specify this in the connection string.
Assuming you have named pipes authentication enabled in SQL, your SQL connection string in your ASP.NET application could be configured to use integrated security (Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;). Then in SSMS, give the appropriate ASP.NET user privileges to the database. The user that IIS uses depends on what version of IIS you're running, and can be seen in the App Pool configuration for the server in question.
I'd have to implement my own security for the application (windows form).
The application is for internal use (10 users) but security is very important due to sensitive data. (SQL Server 2008 is in the back end, .NET 4.0)
I don't have a login form but I have a connection string in app.config. So I guess that maybe app.config is a good place to implement AD groups? Or borrow asp.net membership provider?
Thanks for advice.
If you're trying to maintain database permissions, set them on the database and have your application use Integrated Security=True in the connection string. The user will connect as themselves to the database and have whatever permissions the database specifies.
Why not just use active directory group membership to control security? Your connection string to the SQL Server database can go in the config file, but you should probably 'encrypt' that before releasing it to clients.
If you're determined to check the user's AD groups and prevent the application from continuing to run on startup, take a look here.